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

Commit 6aa2fdb8 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge branch 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip 

Pull irq updates from Thomas Gleixner:
 "The irq departement delivers:

   - Rework the irqdomain core infrastructure to accomodate ACPI based
     systems.  This is required to support ARM64 without creating
     artificial device tree nodes.

   - Sanitize the ACPI based ARM GIC initialization by making use of the
     new firmware independent irqdomain core

   - Further improvements to the generic MSI management

   - Generalize the irq migration on CPU hotplug

   - Improvements to the threaded interrupt infrastructure

   - Allow the migration of "chained" low level interrupt handlers

   - Allow optional force masking of interrupts in disable_irq[_nosysnc]

   - Support for two new interrupt chips - Sigh!

   - A larger set of errata fixes for ARM gicv3

   - The usual pile of fixes, updates, improvements and cleanups all
     over the place"

* 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (71 commits)
  Document that IRQ_NONE should be returned when IRQ not actually handled
  PCI/MSI: Allow the MSI domain to be device-specific
  PCI: Add per-device MSI domain hook
  of/irq: Use the msi-map property to provide device-specific MSI domain
  of/irq: Split of_msi_map_rid to reuse msi-map lookup
  irqchip/gic-v3-its: Parse new version of msi-parent property
  PCI/MSI: Use of_msi_get_domain instead of open-coded "msi-parent" parsing
  of/irq: Use of_msi_get_domain instead of open-coded "msi-parent" parsing
  of/irq: Add support code for multi-parent version of "msi-parent"
  irqchip/gic-v3-its: Add handling of PCI requester id.
  PCI/MSI: Add helper function pci_msi_domain_get_msi_rid().
  of/irq: Add new function of_msi_map_rid()
  Docs: dt: Add PCI MSI map bindings
  irqchip/gic-v2m: Add support for multiple MSI frames
  irqchip/gic-v3: Fix translation of LPIs after conversion to irq_fwspec
  irqchip/mxs: Add Alphascale ASM9260 support
  irqchip/mxs: Prepare driver for hardware with different offsets
  irqchip/mxs: Panic if ioremap or domain creation fails
  irqdomain: Documentation updates
  irqdomain/msi: Use fwnode instead of of_node
  ...
parents 7b2a4306 d9e4ad5b

Documentation/IRQ-domain.txt

+4 −4
Original line number Original line Diff line number Diff line
@@ -32,9 +32,9 @@ top of the irq_alloc_desc*() API. An irq_domain to manage mapping is 
preferred over interrupt controller drivers open coding their own

preferred over interrupt controller drivers open coding their own

reverse mapping scheme.

reverse mapping scheme.





irq_domain also implements translation from Device Tree interrupt

irq_domain also implements translation from an abstract irq_fwspec

specifiers to hwirq numbers, and can be easily extended to support

structure to hwirq numbers (Device Tree and ACPI GSI so far), and can

other IRQ topology data sources.

be easily extended to support other IRQ topology data sources.





=== irq_domain usage ===

=== irq_domain usage ===

An interrupt controller driver creates and registers an irq_domain by

An interrupt controller driver creates and registers an irq_domain by
@@ -184,7 +184,7 @@ There are four major interfaces to use hierarchy irq_domain: 
   related resources associated with these interrupts.

   related resources associated with these interrupts.

3) irq_domain_activate_irq(): activate interrupt controller hardware to

3) irq_domain_activate_irq(): activate interrupt controller hardware to

   deliver the interrupt.

   deliver the interrupt.

3) irq_domain_deactivate_irq(): deactivate interrupt controller hardware

4) irq_domain_deactivate_irq(): deactivate interrupt controller hardware

   to stop delivering the interrupt.

   to stop delivering the interrupt.





Following changes are needed to support hierarchy irq_domain.

Following changes are needed to support hierarchy irq_domain.

Documentation/arm64/booting.txt

+10 −1
Original line number Original line Diff line number Diff line
@@ -173,13 +173,22 @@ Before jumping into the kernel, the following conditions must be met: 
  the kernel image will be entered must be initialised by software at a

  the kernel image will be entered must be initialised by software at a

  higher exception level to prevent execution in an UNKNOWN state.

  higher exception level to prevent execution in an UNKNOWN state.





  For systems with a GICv3 interrupt controller:

  For systems with a GICv3 interrupt controller to be used in v3 mode:

  - If EL3 is present:

  - If EL3 is present:

    ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.

    ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.

    ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1.

    ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1.

  - If the kernel is entered at EL1:

  - If the kernel is entered at EL1:

    ICC.SRE_EL2.Enable (bit 3) must be initialised to 0b1

    ICC.SRE_EL2.Enable (bit 3) must be initialised to 0b1

    ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b1.

    ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b1.

  - The DT or ACPI tables must describe a GICv3 interrupt controller.



  For systems with a GICv3 interrupt controller to be used in

  compatibility (v2) mode:

  - If EL3 is present:

    ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b0.

  - If the kernel is entered at EL1:

    ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b0.

  - The DT or ACPI tables must describe a GICv2 interrupt controller.





The requirements described above for CPU mode, caches, MMUs, architected

The requirements described above for CPU mode, caches, MMUs, architected

timers, coherency and system registers apply to all CPUs.  All CPUs must

timers, coherency and system registers apply to all CPUs.  All CPUs must

Documentation/devicetree/bindings/arm/gic.txt

+20 −4
Original line number Original line Diff line number Diff line
@@ -11,13 +11,14 @@ have PPIs or SGIs. 
Main node required properties:

Main node required properties:





- compatible : should be one of:

- compatible : should be one of:

	"arm,gic-400"

	"arm,arm1176jzf-devchip-gic"

	"arm,arm11mp-gic"

	"arm,cortex-a15-gic"

	"arm,cortex-a15-gic"

	"arm,cortex-a9-gic"

	"arm,cortex-a7-gic"

	"arm,cortex-a7-gic"

	"arm,arm11mp-gic"

	"arm,cortex-a9-gic"

	"arm,gic-400"

	"arm,pl390"

	"brcm,brahma-b15-gic"

	"brcm,brahma-b15-gic"

	"arm,arm1176jzf-devchip-gic"

	"qcom,msm-8660-qgic"

	"qcom,msm-8660-qgic"

	"qcom,msm-qgic2"

	"qcom,msm-qgic2"

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

- interrupt-controller : Identifies the node as an interrupt controller
@@ -58,6 +59,21 @@ Optional 
  regions, used when the GIC doesn't have banked registers. The offset is

  regions, used when the GIC doesn't have banked registers. The offset is

  cpu-offset * cpu-nr.

  cpu-offset * cpu-nr.





- clocks        : List of phandle and clock-specific pairs, one for each entry

  in clock-names.

- clock-names   : List of names for the GIC clock input(s). Valid clock names

  depend on the GIC variant:

	"ic_clk" (for "arm,arm11mp-gic")

	"PERIPHCLKEN" (for "arm,cortex-a15-gic")

	"PERIPHCLK", "PERIPHCLKEN" (for "arm,cortex-a9-gic")

	"clk" (for "arm,gic-400")

	"gclk" (for "arm,pl390")



- power-domains : A phandle and PM domain specifier as defined by bindings of

		  the power controller specified by phandle, used when the GIC

		  is part of a Power or Clock Domain.





Example:

Example:





	intc: interrupt-controller@fff11000 {

	intc: interrupt-controller@fff11000 {

Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt

+1 −0
Original line number Original line Diff line number Diff line
@@ -10,6 +10,7 @@ Required properties: 
    - "renesas,irqc-r8a7792" (R-Car V2H)

    - "renesas,irqc-r8a7792" (R-Car V2H)

    - "renesas,irqc-r8a7793" (R-Car M2-N)

    - "renesas,irqc-r8a7793" (R-Car M2-N)

    - "renesas,irqc-r8a7794" (R-Car E2)

    - "renesas,irqc-r8a7794" (R-Car E2)

    - "renesas,intc-ex-r8a7795" (R-Car H3)

- #interrupt-cells: has to be <2>: an interrupt index and flags, as defined in

- #interrupt-cells: has to be <2>: an interrupt index and flags, as defined in

  interrupts.txt in this directory

  interrupts.txt in this directory

- clocks: Must contain a reference to the functional clock.

- clocks: Must contain a reference to the functional clock.

Documentation/devicetree/bindings/pci/pci-msi.txt

0 → 100644
+220 −0
Original line number Original line Diff line number Diff line 
This document describes the generic device tree binding for describing the

relationship between PCI devices and MSI controllers.



Each PCI device under a root complex is uniquely identified by its Requester ID

(AKA RID). A Requester ID is a triplet of a Bus number, Device number, and

Function number.



For the purpose of this document, when treated as a numeric value, a RID is

formatted such that:



* Bits [15:8] are the Bus number.

* Bits [7:3] are the Device number.

* Bits [2:0] are the Function number.

* Any other bits required for padding must be zero.



MSIs may be distinguished in part through the use of sideband data accompanying

writes. In the case of PCI devices, this sideband data may be derived from the

Requester ID. A mechanism is required to associate a device with both the MSI

controllers it can address, and the sideband data that will be associated with

its writes to those controllers.



For generic MSI bindings, see

Documentation/devicetree/bindings/interrupt-controller/msi.txt.





PCI root complex

================



Optional properties

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



- msi-map: Maps a Requester ID to an MSI controller and associated

  msi-specifier data. The property is an arbitrary number of tuples of

  (rid-base,msi-controller,msi-base,length), where:



  * rid-base is a single cell describing the first RID matched by the entry.



  * msi-controller is a single phandle to an MSI controller



  * msi-base is an msi-specifier describing the msi-specifier produced for the

    first RID matched by the entry.



  * length is a single cell describing how many consecutive RIDs are matched

    following the rid-base.



  Any RID r in the interval [rid-base, rid-base + length) is associated with

  the listed msi-controller, with the msi-specifier (r - rid-base + msi-base).



- msi-map-mask: A mask to be applied to each Requester ID prior to being mapped

  to an msi-specifier per the msi-map property.



- msi-parent: Describes the MSI parent of the root complex itself. Where

  the root complex and MSI controller do not pass sideband data with MSI

  writes, this property may be used to describe the MSI controller(s)

  used by PCI devices under the root complex, if defined as such in the

  binding for the root complex.





Example (1)

===========



/ {

	#address-cells = <1>;

	#size-cells = <1>;



	msi: msi-controller@a {

		reg = <0xa 0x1>;

		compatible = "vendor,some-controller";

		msi-controller;

		#msi-cells = <1>;

	};



	pci: pci@f {

		reg = <0xf 0x1>;

		compatible = "vendor,pcie-root-complex";

		device_type = "pci";



		/*

		 * The sideband data provided to the MSI controller is

		 * the RID, identity-mapped.

		 */

		msi-map = <0x0 &msi_a 0x0 0x10000>,

	};

};





Example (2)

===========



/ {

	#address-cells = <1>;

	#size-cells = <1>;



	msi: msi-controller@a {

		reg = <0xa 0x1>;

		compatible = "vendor,some-controller";

		msi-controller;

		#msi-cells = <1>;

	};



	pci: pci@f {

		reg = <0xf 0x1>;

		compatible = "vendor,pcie-root-complex";

		device_type = "pci";



		/*

		 * The sideband data provided to the MSI controller is

		 * the RID, masked to only the device and function bits.

		 */

		msi-map = <0x0 &msi_a 0x0 0x100>,

		msi-map-mask = <0xff>

	};

};





Example (3)

===========



/ {

	#address-cells = <1>;

	#size-cells = <1>;



	msi: msi-controller@a {

		reg = <0xa 0x1>;

		compatible = "vendor,some-controller";

		msi-controller;

		#msi-cells = <1>;

	};



	pci: pci@f {

		reg = <0xf 0x1>;

		compatible = "vendor,pcie-root-complex";

		device_type = "pci";



		/*

		 * The sideband data provided to the MSI controller is

		 * the RID, but the high bit of the bus number is

		 * ignored.

		 */

		msi-map = <0x0000 &msi 0x0000 0x8000>,

			  <0x8000 &msi 0x0000 0x8000>;

	};

};





Example (4)

===========



/ {

	#address-cells = <1>;

	#size-cells = <1>;



	msi: msi-controller@a {

		reg = <0xa 0x1>;

		compatible = "vendor,some-controller";

		msi-controller;

		#msi-cells = <1>;

	};



	pci: pci@f {

		reg = <0xf 0x1>;

		compatible = "vendor,pcie-root-complex";

		device_type = "pci";



		/*

		 * The sideband data provided to the MSI controller is

		 * the RID, but the high bit of the bus number is

		 * negated.

		 */

		msi-map = <0x0000 &msi 0x8000 0x8000>,

			  <0x8000 &msi 0x0000 0x8000>;

	};

};





Example (5)

===========



/ {

	#address-cells = <1>;

	#size-cells = <1>;



	msi_a: msi-controller@a {

		reg = <0xa 0x1>;

		compatible = "vendor,some-controller";

		msi-controller;

		#msi-cells = <1>;

	};



	msi_b: msi-controller@b {

		reg = <0xb 0x1>;

		compatible = "vendor,some-controller";

		msi-controller;

		#msi-cells = <1>;

	};



	msi_c: msi-controller@c {

		reg = <0xc 0x1>;

		compatible = "vendor,some-controller";

		msi-controller;

		#msi-cells = <1>;

	};



	pci: pci@c {

		reg = <0xf 0x1>;

		compatible = "vendor,pcie-root-complex";

		device_type = "pci";



		/*

		 * The sideband data provided to MSI controller a is the

		 * RID, but the high bit of the bus number is negated.

		 * The sideband data provided to MSI controller b is the

		 * RID, identity-mapped.

		 * MSI controller c is not addressable.

		 */

		msi-map = <0x0000 &msi_a 0x8000 0x08000>,

			  <0x8000 &msi_a 0x0000 0x08000>,

			  <0x0000 &msi_b 0x0000 0x10000>;

	};

};