Merge remote-tracking branch 'origin/v3.18/topic/pcie/master' into linux-linaro-lsk-v3.18

that the driver using the simple domain call irq_create_mapping()

before any irq_find_mapping() since the latter will actually work

for the static IRQ assignment case.

==== Hierarchy IRQ domain ====

On some architectures, there may be multiple interrupt controllers

involved in delivering an interrupt from the device to the target CPU.

Let's look at a typical interrupt delivering path on x86 platforms:

Device --> IOAPIC -> Interrupt remapping Controller -> Local APIC -> CPU

There are three interrupt controllers involved:

1) IOAPIC controller

2) Interrupt remapping controller

3) Local APIC controller

To support such a hardware topology and make software architecture match

hardware architecture, an irq_domain data structure is built for each

interrupt controller and those irq_domains are organized into hierarchy.

When building irq_domain hierarchy, the irq_domain near to the device is

child and the irq_domain near to CPU is parent. So a hierarchy structure

as below will be built for the example above.

	CPU Vector irq_domain (root irq_domain to manage CPU vectors)

		^

		|

	Interrupt Remapping irq_domain (manage irq_remapping entries)

		^

		|

	IOAPIC irq_domain (manage IOAPIC delivery entries/pins)

There are four major interfaces to use hierarchy irq_domain:

1) irq_domain_alloc_irqs(): allocate IRQ descriptors and interrupt

   controller related resources to deliver these interrupts.

2) irq_domain_free_irqs(): free IRQ descriptors and interrupt controller

   related resources associated with these interrupts.

3) irq_domain_activate_irq(): activate interrupt controller hardware to

   deliver the interrupt.

3) irq_domain_deactivate_irq(): deactivate interrupt controller hardware

   to stop delivering the interrupt.

Following changes are needed to support hierarchy irq_domain.

1) a new field 'parent' is added to struct irq_domain; it's used to

   maintain irq_domain hierarchy information.

2) a new field 'parent_data' is added to struct irq_data; it's used to

   build hierarchy irq_data to match hierarchy irq_domains. The irq_data

   is used to store irq_domain pointer and hardware irq number.

3) new callbacks are added to struct irq_domain_ops to support hierarchy

   irq_domain operations.

With support of hierarchy irq_domain and hierarchy irq_data ready, an

irq_domain structure is built for each interrupt controller, and an

irq_data structure is allocated for each irq_domain associated with an

IRQ. Now we could go one step further to support stacked(hierarchy)

irq_chip. That is, an irq_chip is associated with each irq_data along

the hierarchy. A child irq_chip may implement a required action by

itself or by cooperating with its parent irq_chip.

With stacked irq_chip, interrupt controller driver only needs to deal

with the hardware managed by itself and may ask for services from its

parent irq_chip when needed. So we could achieve a much cleaner

software architecture.

For an interrupt controller driver to support hierarchy irq_domain, it

needs to:

1) Implement irq_domain_ops.alloc and irq_domain_ops.free

2) Optionally implement irq_domain_ops.activate and

   irq_domain_ops.deactivate.

3) Optionally implement an irq_chip to manage the interrupt controller

   hardware.

4) No need to implement irq_domain_ops.map and irq_domain_ops.unmap,

   they are unused with hierarchy irq_domain.

Hierarchy irq_domain may also be used to support other architectures,

such as ARM, ARM64 etc.

- core-module: the root node to the Versatile platforms must have

  a core-module with regs and the compatible strings

  "arm,core-module-versatile", "syscon"

ARM RealView Boards

-------------------

The RealView boards cover tailored evaluation boards that are used to explore

the ARM11 and Cortex A-8 and Cortex A-9 processors.

Required properties (in root node):

	/* RealView Emulation Baseboard */

	compatible = "arm,realview-eb";

	 /* RealView Platform Baseboard for ARM1176JZF-S */

	compatible = "arm,realview-pb1176";

	/* RealView Platform Baseboard for ARM11 MPCore */

	compatible = "arm,realview-pb11mp";

	/* RealView Platform Baseboard for Cortex A-8 */

	compatible = "arm,realview-pba8";

	/* RealView Platform Baseboard Explore for Cortex A-9 */

	compatible = "arm,realview-pbx";

Required nodes:

- soc: some node of the RealView platforms must be the SoC

  node that contain the SoC-specific devices, withe the compatible

  string set to one of these tuples:

   "arm,realview-eb-soc", "simple-bus"

   "arm,realview-pb1176-soc", "simple-bus"

   "arm,realview-pb11mp-soc", "simple-bus"

   "arm,realview-pba8-soc", "simple-bus"

   "arm,realview-pbx-soc", "simple-bus"

- syscon: some subnode of the RealView SoC node must be a

  system controller node pointing to the control registers,

  with the compatible string set to one of these tuples:

   "arm,realview-eb-syscon", "syscon"

   "arm,realview-pb1176-syscon", "syscon"

   "arm,realview-pb11mp-syscon", "syscon"

   "arm,realview-pba8-syscon", "syscon"

   "arm,realview-pbx-syscon", "syscon"

  Required properties for the system controller:

  - regs: the location and size of the system controller registers,

    one range of 0x1000 bytes.

Example:

/dts-v1/;

#include <dt-bindings/interrupt-controller/irq.h>

#include "skeleton.dtsi"

/ {

	model = "ARM RealView PB1176 with device tree";

	compatible = "arm,realview-pb1176";

	soc {

		#address-cells = <1>;

		#size-cells = <1>;

		compatible = "arm,realview-pb1176-soc", "simple-bus";

		ranges;

		syscon: syscon@10000000 {

			compatible = "arm,realview-syscon", "syscon";

			reg = <0x10000000 0x1000>;

		};

	};

};

ARM Versatile Express Boards

-----------------------------

For details on the device tree bindings for ARM Versatile Express boards

please consult the vexpress.txt file in the same directory as this file.

ARM Juno Boards

----------------

The Juno boards are targeting development for AArch64 systems. The first

iteration, Juno r0, is a vehicle for evaluating big.LITTLE on AArch64,

with the second iteration, Juno r1, mainly aimed at development of PCIe

based systems. Juno r1 also has support for AXI masters placed on the TLX

connectors to join the coherency domain.

Juno boards are described in a similar way to ARM Versatile Express boards,

with the motherboard part of the hardware being described in a separate file

to highlight the fact that is part of the support infrastructure for the SoC.

Juno device tree bindings also share the Versatile Express bindings as

described under the RS1 memory mapping.

Required properties (in root node):

	compatible = "arm,juno";	/* For Juno r0 board */

	compatible = "arm,juno-r1";	/* For Juno r1 board */

Required nodes:

The description for the board must include:

   - a "psci" node describing the boot method used for the secondary CPUs.

     A detailed description of the bindings used for "psci" nodes is present

     in the psci.txt file.

   - a "cpus" node describing the available cores and their associated

     "enable-method"s. For more details see cpus.txt file.

Example:

/dts-v1/;

/ {

	model = "ARM Juno development board (r0)";

	compatible = "arm,juno", "arm,vexpress";

	interrupt-parent = <&gic>;

	#address-cells = <2>;

	#size-cells = <2>;

	cpus {

		#address-cells = <2>;

		#size-cells = <0>;

		A57_0: cpu@0 {

			compatible = "arm,cortex-a57","arm,armv8";

			reg = <0x0 0x0>;

			device_type = "cpu";

			enable-method = "psci";

		};

		.....

		A53_0: cpu@100 {

			compatible = "arm,cortex-a53","arm,armv8";

			reg = <0x0 0x100>;

			device_type = "cpu";

			enable-method = "psci";

		};

		.....

	};

};

  occupied by the redistributors. Required if more than one such

  region is present.

Sub-nodes:

GICv3 has one or more Interrupt Translation Services (ITS) that are

used to route Message Signalled Interrupts (MSI) to the CPUs.

These nodes must have the following properties:

- compatible : Should at least contain  "arm,gic-v3-its".

- msi-controller : Boolean property. Identifies the node as an MSI controller

- reg: Specifies the base physical address and size of the ITS

  registers.

The main GIC node must contain the appropriate #address-cells,

#size-cells and ranges properties for the reg property of all ITS

nodes.

Examples:

	gic: interrupt-controller@2cf00000 {

		compatible = "arm,gic-v3";

		#interrupt-cells = <3>;

		#address-cells = <2>;

		#size-cells = <2>;

		ranges;

		interrupt-controller;

		reg = <0x0 0x2f000000 0 0x10000>,	// GICD

		      <0x0 0x2f100000 0 0x200000>,	// GICR

		      <0x0 0x2c010000 0 0x2000>,	// GICH

		      <0x0 0x2c020000 0 0x2000>;	// GICV

		interrupts = <1 9 4>;

		gic-its@2c200000 {

			compatible = "arm,gic-v3-its";

			msi-controller;

			reg = <0x0 0x2c200000 0 0x200000>;

		};

	};

	gic: interrupt-controller@2c010000 {

		compatible = "arm,gic-v3";

		#interrupt-cells = <3>;

		#address-cells = <2>;

		#size-cells = <2>;

		ranges;

		interrupt-controller;

		redistributor-stride = <0x0 0x40000>;	// 256kB stride

		#redistributor-regions = <2>;

		      <0x0 0x2c060000 0 0x2000>,	// GICH

		      <0x0 0x2c080000 0 0x2000>;	// GICV

		interrupts = <1 9 4>;

		gic-its@2c200000 {

			compatible = "arm,gic-v3-its";

			msi-controller;

			reg = <0x0 0x2c200000 0 0x200000>;

		};

		gic-its@2c400000 {

			compatible = "arm,gic-v3-its";

			msi-controller;

			reg = <0x0 0x2c400000 0 0x200000>;

		};

	};

  The 3rd cell is the flags, encoded as follows:

	bits[3:0] trigger type and level flags.

		1 = low-to-high edge triggered

		2 = high-to-low edge triggered

		2 = high-to-low edge triggered (invalid for SPIs)

		4 = active high level-sensitive

		8 = active low level-sensitive

		8 = active low level-sensitive (invalid for SPIs).

	bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to each of

	the 8 possible cpus attached to the GIC.  A bit set to '1' indicated

	the interrupt is wired to that CPU.  Only valid for PPI interrupts.

	Also note that the configurability of PPI interrupts is IMPLEMENTATION

	DEFINED and as such not guaranteed to be present (most SoC available

	in 2014 seem to ignore the setting of this flag and use the hardware

	default value).

- reg : Specifies base physical address(s) and size of the GIC registers. The

  first region is the GIC distributor register base and size. The 2nd region is

		      <0x2c006000 0x2000>;

		interrupts = <1 9 0xf04>;

	};

* GICv2m extension for MSI/MSI-x support (Optional)

Certain revisions of GIC-400 supports MSI/MSI-x via V2M register frame(s).

This is enabled by specifying v2m sub-node(s).

Required properties:

- compatible	    : The value here should contain "arm,gic-v2m-frame".

- msi-controller    : Identifies the node as an MSI controller.

- reg		    : GICv2m MSI interface register base and size

Optional properties:

- arm,msi-base-spi  : When the MSI_TYPER register contains an incorrect

  		      value, this property should contain the SPI base of

		      the MSI frame, overriding the HW value.

- arm,msi-num-spis  : When the MSI_TYPER register contains an incorrect

  		      value, this property should contain the number of

		      SPIs assigned to the frame, overriding the HW value.

Example:

	interrupt-controller@e1101000 {

		compatible = "arm,gic-400";

		#interrupt-cells = <3>;

		#address-cells = <2>;

		#size-cells = <2>;

		interrupt-controller;

		interrupts = <1 8 0xf04>;

		ranges = <0 0 0 0xe1100000 0 0x100000>;

		reg = <0x0 0xe1110000 0 0x01000>,

		      <0x0 0xe112f000 0 0x02000>,

		      <0x0 0xe1140000 0 0x10000>,

		      <0x0 0xe1160000 0 0x10000>;

		v2m0: v2m@0x8000 {

			compatible = "arm,gic-v2m-frame";

			msi-controller;

			reg = <0x0 0x80000 0 0x1000>;

		};

		....

		v2mN: v2m@0x9000 {

			compatible = "arm,gic-v2m-frame";

			msi-controller;

			reg = <0x0 0x90000 0 0x1000>;

		};

	};

Mediatek 65xx/81xx sysirq

Mediatek SOCs sysirq support controllable irq inverter for each GIC SPI

interrupt.

Required properties:

- compatible: should be one of:

	"mediatek,mt8135-sysirq"

	"mediatek,mt8127-sysirq"

	"mediatek,mt6589-sysirq"

	"mediatek,mt6582-sysirq"

	"mediatek,mt6577-sysirq"

- interrupt-controller : Identifies the node as an interrupt controller

- #interrupt-cells : Use the same format as specified by GIC in

  Documentation/devicetree/bindings/arm/gic.txt

- interrupt-parent: phandle of irq parent for sysirq. The parent must

  use the same interrupt-cells format as GIC.

- reg: Physical base address of the intpol registers and length of memory

  mapped region.

Example:

	sysirq: interrupt-controller@10200100 {

		compatible = "mediatek,mt6589-sysirq", "mediatek,mt6577-sysirq";

		interrupt-controller;

		#interrupt-cells = <3>;

		interrupt-parent = <&gic>;

		reg = <0 0x10200100 0 0x1c>;

	};