diff mbox series

[v4,2/2] dt/bindings: Add bindings for Layerscape external irqs

Message ID 20180125150230.7234-2-rasmus.villemoes@prevas.dk
State Changes Requested, archived
Headers show
Series None | expand

Commit Message

Rasmus Villemoes Jan. 25, 2018, 3:02 p.m. UTC
This adds Device Tree binding documentation for the external interrupt
lines with configurable polarity present on some Layerscape SOCs.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
Changes since v3: Add non-empty commit log.

.../interrupt-controller/fsl,ls-extirq.txt         | 44 ++++++++++++++++++++++
 1 file changed, 44 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt

Comments

Rob Herring Feb. 5, 2018, 6:07 a.m. UTC | #1
On Thu, Jan 25, 2018 at 04:02:30PM +0100, Rasmus Villemoes wrote:
> This adds Device Tree binding documentation for the external interrupt
> lines with configurable polarity present on some Layerscape SOCs.
> 
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> ---
> Changes since v3: Add non-empty commit log.
> 
> .../interrupt-controller/fsl,ls-extirq.txt         | 44 ++++++++++++++++++++++
>  1 file changed, 44 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
> 
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
> new file mode 100644
> index 000000000000..a71ce2c3eeae
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
> @@ -0,0 +1,44 @@
> +* Freescale Layerscape external IRQs
> +
> +Some Layerscape SOCs (LS1021A, LS1043A, LS1046A) support inverting
> +the polarity of certain external interrupt lines.
> +
> +The device node must be a child of the node representing the
> +Supplemental Configuration Unit (SCFG).
> +
> +Required properties:
> +- compatible: should be "fsl,<soc-name>-extirq", e.g. "fsl,ls1021a-extirq".
> +- interrupt-controller: Identifies the node as an interrupt controller
> +- #interrupt-cells: Use the same format as specified by GIC in arm,gic.txt.
> +- interrupt-parent: phandle of GIC.
> +- offset: offset to the Interrupt Polarity Control Register (INTPCR)
> +  register in the SCFG.
> +- interrupts: Specifies the mapping to interrupt numbers in the parent
> +  interrupt controller. Interrupts are mapped one-to-one to parent
> +  interrupts.
> +
> +Optional properties:
> +- fsl,bit-reverse: This boolean property should be set on the LS1021A
> +  if the SCFGREVCR register has been set to all-ones (which is usually
> +  the case), meaning that all reads and writes of SCFG registers are
> +  implicitly bit-reversed. Other compatible platforms do not have such
> +  a register.
> +
> +Example:
> +	scfg: scfg@1570000 {
> +		compatible = "fsl,ls1021a-scfg", "syscon";
> +		...
> +		extirq: interrupt-controller {
> +			compatible = "fsl,ls1021a-extirq";
> +			#interrupt-cells = <3>;
> +			interrupt-controller;
> +			interrupt-parent = <&gic>;
> +			offset = <0x1ac>;

Use reg here instead (with a length).

> +			interrupts = <163 164 165 167 168 169>;

These don't look like GIC interrupt cells. Building this with current 
dtc will have errors.

> +			fsl,bit-reverse;
> +		};
> +	};
> +
> +
> +	interrupts-extended = <&gic GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
> +			      <&extirq GIC_SPI 1 IRQ_TYPE_LEVEL_LOW>;
> -- 
> 2.15.1
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rasmus Villemoes Feb. 8, 2018, 3:08 p.m. UTC | #2
On 2018-02-05 07:07, Rob Herring wrote:
>> +Example:
>> +	scfg: scfg@1570000 {
>> +		compatible = "fsl,ls1021a-scfg", "syscon";
>> +		...
>> +		extirq: interrupt-controller {
>> +			compatible = "fsl,ls1021a-extirq";
>> +			#interrupt-cells = <3>;
>> +			interrupt-controller;
>> +			interrupt-parent = <&gic>;
>> +			offset = <0x1ac>;
> 
> Use reg here instead (with a length).

Hm, ok, but what does the length buy us? Should the driver just ignore
it, or should it check that it is 4 and bail out if not?

>> +			interrupts = <163 164 165 167 168 169>;
> 
> These don't look like GIC interrupt cells. Building this with current 
> dtc will have errors.

Indeed, they are not. They simply record which interrupt lines on the
GIC the external interrupt lines IRQ0...IRQ5 map to (the arm64 socs
apparently have 12 such lines, but I don't know what they map to). I
originally had that mapping in the driver, but I was asked to move it to
DT. Is the problem the use of the name "interrupts" for this property?
I'm happy to use something else (parent-interrupts, interrupt-mapping,
...) I find it very hard to figure out which property names have
magic/reserved meanings.

I don't see any warnings/errors from dtc in the 4.14 tree I'm working
on. Does it require an even newer dtc than that?

Thanks,
Rasmus
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Marc Zyngier Feb. 9, 2018, 9:47 a.m. UTC | #3
On 08/02/18 15:08, Rasmus Villemoes wrote:
> On 2018-02-05 07:07, Rob Herring wrote:
>>> +Example:
>>> +	scfg: scfg@1570000 {
>>> +		compatible = "fsl,ls1021a-scfg", "syscon";
>>> +		...
>>> +		extirq: interrupt-controller {
>>> +			compatible = "fsl,ls1021a-extirq";
>>> +			#interrupt-cells = <3>;
>>> +			interrupt-controller;
>>> +			interrupt-parent = <&gic>;
>>> +			offset = <0x1ac>;
>>
>> Use reg here instead (with a length).
> 
> Hm, ok, but what does the length buy us? Should the driver just ignore
> it, or should it check that it is 4 and bail out if not?
> 
>>> +			interrupts = <163 164 165 167 168 169>;
>>
>> These don't look like GIC interrupt cells. Building this with current 
>> dtc will have errors.
> 
> Indeed, they are not. They simply record which interrupt lines on the
> GIC the external interrupt lines IRQ0...IRQ5 map to (the arm64 socs
> apparently have 12 such lines, but I don't know what they map to). I
> originally had that mapping in the driver, but I was asked to move it to
> DT. Is the problem the use of the name "interrupts" for this property?
> I'm happy to use something else (parent-interrupts, interrupt-mapping,
> ...) I find it very hard to figure out which property names have
> magic/reserved meanings.
> 
> I don't see any warnings/errors from dtc in the 4.14 tree I'm working
> on. Does it require an even newer dtc than that?

Most interrupt controllers use a private property, potentially with a
range (see the recent example of the Qualcomm PDC [1]).

Thanks,

	M.

[1] https://patchwork.kernel.org/patch/10208037/
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
new file mode 100644
index 000000000000..a71ce2c3eeae
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
@@ -0,0 +1,44 @@ 
+* Freescale Layerscape external IRQs
+
+Some Layerscape SOCs (LS1021A, LS1043A, LS1046A) support inverting
+the polarity of certain external interrupt lines.
+
+The device node must be a child of the node representing the
+Supplemental Configuration Unit (SCFG).
+
+Required properties:
+- compatible: should be "fsl,<soc-name>-extirq", e.g. "fsl,ls1021a-extirq".
+- interrupt-controller: Identifies the node as an interrupt controller
+- #interrupt-cells: Use the same format as specified by GIC in arm,gic.txt.
+- interrupt-parent: phandle of GIC.
+- offset: offset to the Interrupt Polarity Control Register (INTPCR)
+  register in the SCFG.
+- interrupts: Specifies the mapping to interrupt numbers in the parent
+  interrupt controller. Interrupts are mapped one-to-one to parent
+  interrupts.
+
+Optional properties:
+- fsl,bit-reverse: This boolean property should be set on the LS1021A
+  if the SCFGREVCR register has been set to all-ones (which is usually
+  the case), meaning that all reads and writes of SCFG registers are
+  implicitly bit-reversed. Other compatible platforms do not have such
+  a register.
+
+Example:
+	scfg: scfg@1570000 {
+		compatible = "fsl,ls1021a-scfg", "syscon";
+		...
+		extirq: interrupt-controller {
+			compatible = "fsl,ls1021a-extirq";
+			#interrupt-cells = <3>;
+			interrupt-controller;
+			interrupt-parent = <&gic>;
+			offset = <0x1ac>;
+			interrupts = <163 164 165 167 168 169>;
+			fsl,bit-reverse;
+		};
+	};
+
+
+	interrupts-extended = <&gic GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
+			      <&extirq GIC_SPI 1 IRQ_TYPE_LEVEL_LOW>;