Loading Documentation/IRQ-domain.txt +71 −0 Original line number Diff line number Diff line Loading @@ -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. Documentation/devicetree/bindings/arm/arm-boards +131 −0 Original line number Diff line number Diff line Loading @@ -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"; }; ..... }; }; Documentation/devicetree/bindings/arm/gic-v3.txt +39 −0 Original line number Diff line number Diff line Loading @@ -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 Loading @@ -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>; Loading @@ -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>; }; }; Documentation/devicetree/bindings/arm/gic.txt +59 −2 Original line number Diff line number Diff line Loading @@ -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 Loading Loading @@ -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>; }; }; Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt 0 → 100644 +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
Documentation/IRQ-domain.txt +71 −0 Original line number Diff line number Diff line Loading @@ -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.
Documentation/devicetree/bindings/arm/arm-boards +131 −0 Original line number Diff line number Diff line Loading @@ -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"; }; ..... }; };
Documentation/devicetree/bindings/arm/gic-v3.txt +39 −0 Original line number Diff line number Diff line Loading @@ -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 Loading @@ -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>; Loading @@ -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>; }; };
Documentation/devicetree/bindings/arm/gic.txt +59 −2 Original line number Diff line number Diff line Loading @@ -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 Loading Loading @@ -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>; }; };
Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt 0 → 100644 +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>; };