Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit e45ef1e5 authored by Kevin Hilman's avatar Kevin Hilman
Browse files

Merge branch 'linux-linaro-lsk-v3.18' into linux-linaro-lsk-v3.18-android

parents b6982cb0 e46761bb
Loading
Loading
Loading
Loading
+71 −0
Original line number Diff line number Diff line
@@ -151,3 +151,74 @@ used and no descriptor gets allocated it is very important to make sure
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.
+131 −0
Original line number Diff line number Diff line
@@ -92,3 +92,134 @@ Required nodes:
- 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";
		};

		.....
	};

};
+39 −0
Original line number Diff line number Diff line
@@ -49,11 +49,29 @@ Optional
  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
@@ -61,11 +79,20 @@ Examples:
		      <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>;
@@ -76,4 +103,16 @@ Examples:
		      <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>;
		};
	};
+59 −2
Original line number Diff line number Diff line
@@ -31,12 +31,16 @@ Main node required properties:
  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
@@ -96,3 +100,56 @@ Example:
		      <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>;
		};
	};
+28 −0
Original line number Diff line number Diff line
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>;
	};
Loading