| Message ID | 1409350479-19108-4-git-send-email-abrestic@chromium.org |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Friday 29 August 2014 15:14:30 Andrew Bresticker wrote: > The Global Interrupt Controller (GIC) present on certain MIPS systems > can be used to route external interrupts to individual VPEs and CPU > interrupt vectors. It also supports a timer and software-generated > interrupts. > > Signed-off-by: Andrew Bresticker <abrestic@chromium.org> > --- > Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++ > This may be a stupid question, but is this related to the ARM GIC in any way or does it just share the name? In either case the binding belongs into Documentation/devicetree/bindings/interrupt-controller/. The ARM one should be moved there as well, and then we have to come up with a new name for the files when there is a conflict. Arnd -- 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
On Sat, Aug 30, 2014 at 12:53 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Friday 29 August 2014 15:14:30 Andrew Bresticker wrote: >> The Global Interrupt Controller (GIC) present on certain MIPS systems >> can be used to route external interrupts to individual VPEs and CPU >> interrupt vectors. It also supports a timer and software-generated >> interrupts. >> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org> >> --- >> Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++ >> > > This may be a stupid question, but is this related to the ARM GIC > in any way or does it just share the name? There's no relation. Note that it's also "Global Interrupt Controller" vs. "Generic Interrupt Controller". > In either case the binding belongs into > Documentation/devicetree/bindings/interrupt-controller/. Will do. -- 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
On Fri, Aug 29, 2014 at 11:14:30PM +0100, Andrew Bresticker wrote: > The Global Interrupt Controller (GIC) present on certain MIPS systems > can be used to route external interrupts to individual VPEs and CPU > interrupt vectors. It also supports a timer and software-generated > interrupts. > > Signed-off-by: Andrew Bresticker <abrestic@chromium.org> > --- > Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++ > 1 file changed, 50 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mips/gic.txt > > diff --git a/Documentation/devicetree/bindings/mips/gic.txt b/Documentation/devicetree/bindings/mips/gic.txt > new file mode 100644 > index 0000000..725f1ef > --- /dev/null > +++ b/Documentation/devicetree/bindings/mips/gic.txt > @@ -0,0 +1,50 @@ > +MIPS Global Interrupt Controller (GIC) > + > +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins. > +It also supports a timer and software-generated interrupts which can be > +used as IPIs. > + > +Required properties: > +- compatible : Should be "mti,global-interrupt-controller" I couldn't find "mti" in vendor-prefixes.txt (as of v3.17-rc3). If there's not a patch to add it elsewhere, would you mind providing one with this series? > +- reg : Base address and length of the GIC registers. > +- interrupts : Core interrupts to which the GIC may route external interrupts. How many? in any order? > +- interrupt-controller : Identifies the node as an interrupt controller > +- #interrupt-cells : Specifies the number of cells needed to encode an > + interrupt specifier. Should be 3. > + - The first cell is the GIC interrupt number. > + - The second cell encodes the interrupt flags. > + See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid > + flags. Are all the flags valid for this interrupt controller? > + - The optional third cell indicates which CPU interrupt vector the GIC > + interrupt should be routed to. It is a 0-based index into the list of > + GIC-to-CPU interrupts specified in the "interrupts" property described > + above. For example, a '2' in this cell will route the interrupt to the > + 3rd core interrupt listed in 'interrupts'. If omitted, the interrupt will > + be routed to the 1st core interrupt. I don't follow why this should be in the DT. Why is this necessary? I also don't follow how this can be ommitted, given interrupt-cells is required to be three by the wording above. > + > +Example: > + > + cpu_intc: interrupt-controller@0 { Nit: there's no reg on this node, so there shouldn't be a unit-address. Thanks, Mark. > + compatible = "mti,cpu-interrupt-controller"; > + > + interrupt-controller; > + #interrupt-cells = <1>; > + }; > + > + gic: interrupt-controller@1bdc0000 { > + compatible = "mti,global-interrupt-controller"; > + reg = <0x1bdc0000 0x20000>; > + > + interrupt-controller; > + #interrupt-cells = <3>; > + > + interrupt-parent = <&cpu_intc>; > + interrupts = <3>, <4>; > + }; > + > + uart@18101400 { > + ... > + interrupt-parent = <&gic>; > + interrupts = <24 IRQ_TYPE_LEVEL_HIGH 0>; > + ... > + }; > -- > 2.1.0.rc2.206.gedb03e5 > > -- > 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 > -- 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
On 01/09/14 12:01, Mark Rutland wrote: > On Fri, Aug 29, 2014 at 11:14:30PM +0100, Andrew Bresticker wrote: >> +Required properties: >> +- compatible : Should be "mti,global-interrupt-controller" > > I couldn't find "mti" in vendor-prefixes.txt (as of v3.17-rc3). If > there's not a patch to add it elsewhere, would you mind providing one > with this series? It should be noted that there does already exist an "img" prefix in that file which may be more suitable (mti stands for MIPS Technologies Inc.). Though of course it appears the mti prefix is already in use, like "mti,cpu-interrupt-controller" in the binding example. Cheers James -- 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
On Mon, Sep 1, 2014 at 4:01 AM, Mark Rutland <mark.rutland@arm.com> wrote: > On Fri, Aug 29, 2014 at 11:14:30PM +0100, Andrew Bresticker wrote: >> The Global Interrupt Controller (GIC) present on certain MIPS systems >> can be used to route external interrupts to individual VPEs and CPU >> interrupt vectors. It also supports a timer and software-generated >> interrupts. >> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org> >> --- >> Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++ >> 1 file changed, 50 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/mips/gic.txt >> >> diff --git a/Documentation/devicetree/bindings/mips/gic.txt b/Documentation/devicetree/bindings/mips/gic.txt >> new file mode 100644 >> index 0000000..725f1ef >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/mips/gic.txt >> @@ -0,0 +1,50 @@ >> +MIPS Global Interrupt Controller (GIC) >> + >> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins. >> +It also supports a timer and software-generated interrupts which can be >> +used as IPIs. >> + >> +Required properties: >> +- compatible : Should be "mti,global-interrupt-controller" > > I couldn't find "mti" in vendor-prefixes.txt (as of v3.17-rc3). If > there's not a patch to add it elsewhere, would you mind providing one > with this series? Sure. As James points out, "img" could also be used but I chose "mti" since the CPU interrupt controller also uses "mti" and I believe the GIC IP was developed before the acquisition by Imagination (though I'm not sure if that actually matters). >> +- reg : Base address and length of the GIC registers. >> +- interrupts : Core interrupts to which the GIC may route external interrupts. > > How many? Up to 6, one for each of the possible core hardware interrupts (i.e. interrupt vectors 2 - 7). Which ones are available to the GIC depend on the system, for example Malta has an i8259 PIC hooked up to CPU interrupt vector 2, so that vector should not be used by the GIC. > In any order? They can technically be in any order, but when in strictly increasing/decreasing order they can be used along with the 3rd cell (described below) to prioritize interrupts. >> +- interrupt-controller : Identifies the node as an interrupt controller >> +- #interrupt-cells : Specifies the number of cells needed to encode an >> + interrupt specifier. Should be 3. >> + - The first cell is the GIC interrupt number. >> + - The second cell encodes the interrupt flags. >> + See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid >> + flags. > > Are all the flags valid for this interrupt controller? Yes. >> + - The optional third cell indicates which CPU interrupt vector the GIC >> + interrupt should be routed to. It is a 0-based index into the list of >> + GIC-to-CPU interrupts specified in the "interrupts" property described >> + above. For example, a '2' in this cell will route the interrupt to the >> + 3rd core interrupt listed in 'interrupts'. If omitted, the interrupt will >> + be routed to the 1st core interrupt. > > I don't follow why this should be in the DT. Why is this necessary? Since the GIC can route external interrupts to any of the CPU hardware interrupt vectors, it can be used to assign priorities to external interrupts. If the CPU is in vectored interrupt mode, the highest numbered interrupt vector (7) has the highest priority. An example: gic: interrupt-controller@1bdc0000 { ... interrupts = <3>, <4>; ... }; uart { ... interrupt-parent = <&gic>; interrupts = <24 IRQ_TYPE_LEVEL_HIGH 1>; ... }; i2c { ... interrupt-parent = <&gic>; interrupts = <33 IRQ_TYPE_LEVEL_HIGH 0>; ... }; Since the third cell for the UART is '1', it maps to CPU interrupt vector 4 and thus has a higher priority than the I2C (whose third cell is 0, mapping to CPU interrupt vector 3). Perhaps, though, this is an instance of software policy being specified in device-tree. Other options would be to a) evenly distribute the GIC external interrupts across the CPU interrupt vectors available to the GIC, or b) just map all GIC external interrupts to a single interrupt vector. > I also don't follow how this can be ommitted, given interrupt-cells is > required to be three by the wording above. If it's absent, the interrupt will be routed to the first CPU interrupt vector in the list. It's equivalent to the third cell being 0. -- 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
On Tue, Sep 02, 2014 at 01:53:18AM +0100, Andrew Bresticker wrote: > On Mon, Sep 1, 2014 at 4:01 AM, Mark Rutland <mark.rutland@arm.com> wrote: > > On Fri, Aug 29, 2014 at 11:14:30PM +0100, Andrew Bresticker wrote: > >> The Global Interrupt Controller (GIC) present on certain MIPS systems > >> can be used to route external interrupts to individual VPEs and CPU > >> interrupt vectors. It also supports a timer and software-generated > >> interrupts. > >> > >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org> > >> --- > >> Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++ > >> 1 file changed, 50 insertions(+) > >> create mode 100644 Documentation/devicetree/bindings/mips/gic.txt > >> > >> diff --git a/Documentation/devicetree/bindings/mips/gic.txt b/Documentation/devicetree/bindings/mips/gic.txt > >> new file mode 100644 > >> index 0000000..725f1ef > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/mips/gic.txt > >> @@ -0,0 +1,50 @@ > >> +MIPS Global Interrupt Controller (GIC) > >> + > >> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins. > >> +It also supports a timer and software-generated interrupts which can be > >> +used as IPIs. > >> + > >> +Required properties: > >> +- compatible : Should be "mti,global-interrupt-controller" > > > > I couldn't find "mti" in vendor-prefixes.txt (as of v3.17-rc3). If > > there's not a patch to add it elsewhere, would you mind providing one > > with this series? > > Sure. As James points out, "img" could also be used but I chose "mti" > since the CPU interrupt controller also uses "mti" and I believe the > GIC IP was developed before the acquisition by Imagination (though I'm > not sure if that actually matters). Using 'mti' sounds like the right choice to me given both of those points. > >> +- reg : Base address and length of the GIC registers. > >> +- interrupts : Core interrupts to which the GIC may route external interrupts. > > > > How many? > > Up to 6, one for each of the possible core hardware interrupts (i.e. > interrupt vectors 2 - 7). Which ones are available to the GIC depend > on the system, for example Malta has an i8259 PIC hooked up to CPU > interrupt vector 2, so that vector should not be used by the GIC. > > > In any order? > > They can technically be in any order, but when in strictly > increasing/decreasing order they can be used along with the 3rd cell > (described below) to prioritize interrupts. Ok. Could you try to place that into the property description? > >> +- interrupt-controller : Identifies the node as an interrupt controller > >> +- #interrupt-cells : Specifies the number of cells needed to encode an > >> + interrupt specifier. Should be 3. > >> + - The first cell is the GIC interrupt number. > >> + - The second cell encodes the interrupt flags. > >> + See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid > >> + flags. > > > > Are all the flags valid for this interrupt controller? > > Yes. Ok. > >> + - The optional third cell indicates which CPU interrupt vector the GIC > >> + interrupt should be routed to. It is a 0-based index into the list of > >> + GIC-to-CPU interrupts specified in the "interrupts" property described > >> + above. For example, a '2' in this cell will route the interrupt to the > >> + 3rd core interrupt listed in 'interrupts'. If omitted, the interrupt will > >> + be routed to the 1st core interrupt. > > > > I don't follow why this should be in the DT. Why is this necessary? > > Since the GIC can route external interrupts to any of the CPU hardware > interrupt vectors, it can be used to assign priorities to external > interrupts. If the CPU is in vectored interrupt mode, the highest > numbered interrupt vector (7) has the highest priority. An example: > > gic: interrupt-controller@1bdc0000 { > ... > interrupts = <3>, <4>; > ... > }; > > uart { > ... > interrupt-parent = <&gic>; > interrupts = <24 IRQ_TYPE_LEVEL_HIGH 1>; > ... > }; > > i2c { > ... > interrupt-parent = <&gic>; > interrupts = <33 IRQ_TYPE_LEVEL_HIGH 0>; > ... > }; > > Since the third cell for the UART is '1', it maps to CPU interrupt > vector 4 and thus has a higher priority than the I2C (whose third cell > is 0, mapping to CPU interrupt vector 3). > > Perhaps, though, this is an instance of software policy being > specified in device-tree. Other options would be to a) evenly > distribute the GIC external interrupts across the CPU interrupt > vectors available to the GIC, or b) just map all GIC external > interrupts to a single interrupt vector. As a user I don't see why the DT author should be in charge of whether my UART gets higher priority than my I2C controller. That priority is not a fixed property of the interrupt (as the line and flags are). That said, this is a grey area. Are there any cases where this prioritisation is critical on existing devices? > > I also don't follow how this can be ommitted, given interrupt-cells is > > required to be three by the wording above. > > If it's absent, the interrupt will be routed to the first CPU > interrupt vector in the list. It's equivalent to the third cell being > 0. My point is that the wording implies that the third cell is optional on a per-interrupt basis, when in reality it depends on the GIC node's #interrupt-cells and affect all devices with GIC interrupts. If &gic/#interrupt-cells = <3>, the third cell can't be absent. If &gic/interrupt-cells = <2>, the third cell can't be present. So it would be better to describe as something like: When interrupt-cells = <3>, the third cell specifies the priority (in the range X to Y). When #interrupt-cells = <2> all interrupts are assigned the same priority (Z). Thanks, Mark. -- 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
On Tue, Sep 2, 2014 at 2:33 AM, Mark Rutland <mark.rutland@arm.com> wrote: > On Tue, Sep 02, 2014 at 01:53:18AM +0100, Andrew Bresticker wrote: >> On Mon, Sep 1, 2014 at 4:01 AM, Mark Rutland <mark.rutland@arm.com> wrote: >> > On Fri, Aug 29, 2014 at 11:14:30PM +0100, Andrew Bresticker wrote: >> >> The Global Interrupt Controller (GIC) present on certain MIPS systems >> >> can be used to route external interrupts to individual VPEs and CPU >> >> interrupt vectors. It also supports a timer and software-generated >> >> interrupts. >> >> >> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org> >> >> --- >> >> Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++ >> >> 1 file changed, 50 insertions(+) >> >> create mode 100644 Documentation/devicetree/bindings/mips/gic.txt >> >> >> >> diff --git a/Documentation/devicetree/bindings/mips/gic.txt b/Documentation/devicetree/bindings/mips/gic.txt >> >> new file mode 100644 >> >> index 0000000..725f1ef >> >> --- /dev/null >> >> +++ b/Documentation/devicetree/bindings/mips/gic.txt >> >> @@ -0,0 +1,50 @@ >> >> +MIPS Global Interrupt Controller (GIC) >> >> + >> >> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins. >> >> +It also supports a timer and software-generated interrupts which can be >> >> +used as IPIs. >> >> + >> >> +Required properties: >> >> +- compatible : Should be "mti,global-interrupt-controller" >> > >> > I couldn't find "mti" in vendor-prefixes.txt (as of v3.17-rc3). If >> > there's not a patch to add it elsewhere, would you mind providing one >> > with this series? >> >> Sure. As James points out, "img" could also be used but I chose "mti" >> since the CPU interrupt controller also uses "mti" and I believe the >> GIC IP was developed before the acquisition by Imagination (though I'm >> not sure if that actually matters). > > Using 'mti' sounds like the right choice to me given both of those > points. > >> >> +- reg : Base address and length of the GIC registers. >> >> +- interrupts : Core interrupts to which the GIC may route external interrupts. >> > >> > How many? >> >> Up to 6, one for each of the possible core hardware interrupts (i.e. >> interrupt vectors 2 - 7). Which ones are available to the GIC depend >> on the system, for example Malta has an i8259 PIC hooked up to CPU >> interrupt vector 2, so that vector should not be used by the GIC. >> >> > In any order? >> >> They can technically be in any order, but when in strictly >> increasing/decreasing order they can be used along with the 3rd cell >> (described below) to prioritize interrupts. > > Ok. Could you try to place that into the property description? > >> >> +- interrupt-controller : Identifies the node as an interrupt controller >> >> +- #interrupt-cells : Specifies the number of cells needed to encode an >> >> + interrupt specifier. Should be 3. >> >> + - The first cell is the GIC interrupt number. >> >> + - The second cell encodes the interrupt flags. >> >> + See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid >> >> + flags. >> > >> > Are all the flags valid for this interrupt controller? >> >> Yes. > > Ok. > >> >> + - The optional third cell indicates which CPU interrupt vector the GIC >> >> + interrupt should be routed to. It is a 0-based index into the list of >> >> + GIC-to-CPU interrupts specified in the "interrupts" property described >> >> + above. For example, a '2' in this cell will route the interrupt to the >> >> + 3rd core interrupt listed in 'interrupts'. If omitted, the interrupt will >> >> + be routed to the 1st core interrupt. >> > >> > I don't follow why this should be in the DT. Why is this necessary? >> >> Since the GIC can route external interrupts to any of the CPU hardware >> interrupt vectors, it can be used to assign priorities to external >> interrupts. If the CPU is in vectored interrupt mode, the highest >> numbered interrupt vector (7) has the highest priority. An example: >> >> gic: interrupt-controller@1bdc0000 { >> ... >> interrupts = <3>, <4>; >> ... >> }; >> >> uart { >> ... >> interrupt-parent = <&gic>; >> interrupts = <24 IRQ_TYPE_LEVEL_HIGH 1>; >> ... >> }; >> >> i2c { >> ... >> interrupt-parent = <&gic>; >> interrupts = <33 IRQ_TYPE_LEVEL_HIGH 0>; >> ... >> }; >> >> Since the third cell for the UART is '1', it maps to CPU interrupt >> vector 4 and thus has a higher priority than the I2C (whose third cell >> is 0, mapping to CPU interrupt vector 3). >> >> Perhaps, though, this is an instance of software policy being >> specified in device-tree. Other options would be to a) evenly >> distribute the GIC external interrupts across the CPU interrupt >> vectors available to the GIC, or b) just map all GIC external >> interrupts to a single interrupt vector. > > As a user I don't see why the DT author should be in charge of whether > my UART gets higher priority than my I2C controller. That priority is > not a fixed property of the interrupt (as the line and flags are). > > That said, this is a grey area. Are there any cases where this > prioritisation is critical on existing devices? I am not aware of any boards for which this is critical. Malta and SEAD-3 are development boards and do not appear to need any sort of prioritization of GIC interrupts. John Crispin is working on a Mediatek board which has a GIC, but it looks like all external interrupts are routed to a single CPU vector. It's possible that it could be useful on the platform I'm working on, though it's looking more and more unlikely. Given all that, perhaps it's better to stick with the 2-cell (no-prioritization) binding for now and add the 3-cell binding later if necessary. -- 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
On 08/29/2014 03:14 PM, Andrew Bresticker wrote: > The Global Interrupt Controller (GIC) present on certain MIPS systems > can be used to route external interrupts to individual VPEs and CPU > interrupt vectors. It also supports a timer and software-generated > interrupts. > > Signed-off-by: Andrew Bresticker <abrestic@chromium.org> > --- > Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++ > 1 file changed, 50 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mips/gic.txt > > diff --git a/Documentation/devicetree/bindings/mips/gic.txt b/Documentation/devicetree/bindings/mips/gic.txt > new file mode 100644 > index 0000000..725f1ef > --- /dev/null > +++ b/Documentation/devicetree/bindings/mips/gic.txt > @@ -0,0 +1,50 @@ > +MIPS Global Interrupt Controller (GIC) > + > +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins. > +It also supports a timer and software-generated interrupts which can be > +used as IPIs. > + > +Required properties: > +- compatible : Should be "mti,global-interrupt-controller" > +- reg : Base address and length of the GIC registers. > +- interrupts : Core interrupts to which the GIC may route external interrupts. This doesn't make sense to me. The GIC can, and does, route interrupts to all CPU cores in a SMP system. How can there be a concept of only associating it with several interrupt lines on a single CPU in the system? That is not what the GIC does, is it? It is a Global interrupts controller, not local. So specifying device tree bindings that don't show its Global nature seems wrong. > +- interrupt-controller : Identifies the node as an interrupt controller > +- #interrupt-cells : Specifies the number of cells needed to encode an > + interrupt specifier. Should be 3. > + - The first cell is the GIC interrupt number. > + - The second cell encodes the interrupt flags. > + See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid > + flags. > + - The optional third cell indicates which CPU interrupt vector the GIC > + interrupt should be routed to. It is a 0-based index into the list of > + GIC-to-CPU interrupts specified in the "interrupts" property described > + above. For example, a '2' in this cell will route the interrupt to the > + 3rd core interrupt listed in 'interrupts'. If omitted, the interrupt will > + be routed to the 1st core interrupt. > + This seems like a really convoluted way of doing things that really goes against the device tree model. The routing of interrupts through the GIC to a core interrupt is controlled entirely within the GIC hardware and therefore should be a property of the GIC itself, not all the random devices connected upstream to the GIC. It also places policy about the priority of the various interrupts into the device tree. Typically the device tree would contain only information about the topology of the hardware blocks, not arbitrary policy decisions that software could change and still have a perfectly functional system. Therefore I would recommend removing the third cell from the interrupt specifier. > +Example: > + > + cpu_intc: interrupt-controller@0 { > + compatible = "mti,cpu-interrupt-controller"; > + > + interrupt-controller; > + #interrupt-cells = <1>; > + }; > + > + gic: interrupt-controller@1bdc0000 { > + compatible = "mti,global-interrupt-controller"; > + reg = <0x1bdc0000 0x20000>; > + > + interrupt-controller; > + #interrupt-cells = <3>; > + > + interrupt-parent = <&cpu_intc>; > + interrupts = <3>, <4>; > + }; > + > + uart@18101400 { > + ... > + interrupt-parent = <&gic>; > + interrupts = <24 IRQ_TYPE_LEVEL_HIGH 0>; > + ... > + }; > -- 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
On Tue, Sep 2, 2014 at 10:27 AM, David Daney <ddaney.cavm@gmail.com> wrote: > On 08/29/2014 03:14 PM, Andrew Bresticker wrote: >> >> The Global Interrupt Controller (GIC) present on certain MIPS systems >> can be used to route external interrupts to individual VPEs and CPU >> interrupt vectors. It also supports a timer and software-generated >> interrupts. >> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org> >> --- >> Documentation/devicetree/bindings/mips/gic.txt | 50 >> ++++++++++++++++++++++++++ >> 1 file changed, 50 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/mips/gic.txt >> >> diff --git a/Documentation/devicetree/bindings/mips/gic.txt >> b/Documentation/devicetree/bindings/mips/gic.txt >> new file mode 100644 >> index 0000000..725f1ef >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/mips/gic.txt >> @@ -0,0 +1,50 @@ >> +MIPS Global Interrupt Controller (GIC) >> + >> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins. >> +It also supports a timer and software-generated interrupts which can be >> +used as IPIs. >> + >> +Required properties: >> +- compatible : Should be "mti,global-interrupt-controller" >> +- reg : Base address and length of the GIC registers. >> +- interrupts : Core interrupts to which the GIC may route external >> interrupts. > > > This doesn't make sense to me. The GIC can, and does, route interrupts to > all CPU cores in a SMP system. How can there be a concept of only > associating it with several interrupt lines on a single CPU in the system? > That is not what the GIC does, is it? It is a Global interrupts controller, > not local. So specifying device tree bindings that don't show its Global > nature seems wrong. While the GIC can route external interrupts to any HW interrupt vector it may not make sense to actually use all those vectors. For example, the CP0 timer is usually hooked up to HW vector 5 (it could be treated as a GIC local interrupt, though it may still be fixed to HW vector 5). BTW, the Malta example about the i8259 I gave before was wrong - it appears that it actually gets chained with the GIC. What would you suggest instead? Route all GIC interrupts to a single vector? Attempt to distribute them over all 6 vectors? >> +- interrupt-controller : Identifies the node as an interrupt controller >> +- #interrupt-cells : Specifies the number of cells needed to encode an >> + interrupt specifier. Should be 3. >> + - The first cell is the GIC interrupt number. >> + - The second cell encodes the interrupt flags. >> + See <include/dt-bindings/interrupt-controller/irq.h> for a list of >> valid >> + flags. >> + - The optional third cell indicates which CPU interrupt vector the GIC >> + interrupt should be routed to. It is a 0-based index into the list >> of >> + GIC-to-CPU interrupts specified in the "interrupts" property >> described >> + above. For example, a '2' in this cell will route the interrupt to >> the >> + 3rd core interrupt listed in 'interrupts'. If omitted, the interrupt >> will >> + be routed to the 1st core interrupt. >> + > > > This seems like a really convoluted way of doing things that really goes > against the device tree model. > > The routing of interrupts through the GIC to a core interrupt is controlled > entirely within the GIC hardware and therefore should be a property of the > GIC itself, not all the random devices connected upstream to the GIC. > > It also places policy about the priority of the various interrupts into the > device tree. Typically the device tree would contain only information about > the topology of the hardware blocks, not arbitrary policy decisions that > software could change and still have a perfectly functional system. > > Therefore I would recommend removing the third cell from the interrupt > specifier. As Mark mentioned, putting priority policy in the DT is a bit of a gray area. Since I don't see any need for it currently, I've decided to drop it. -- 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
On 09/02/2014 12:36 PM, Andrew Bresticker wrote: > On Tue, Sep 2, 2014 at 10:27 AM, David Daney <ddaney.cavm@gmail.com> wrote: >> On 08/29/2014 03:14 PM, Andrew Bresticker wrote: >>> >>> The Global Interrupt Controller (GIC) present on certain MIPS systems >>> can be used to route external interrupts to individual VPEs and CPU >>> interrupt vectors. It also supports a timer and software-generated >>> interrupts. >>> >>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org> >>> --- >>> Documentation/devicetree/bindings/mips/gic.txt | 50 >>> ++++++++++++++++++++++++++ >>> 1 file changed, 50 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/mips/gic.txt >>> >>> diff --git a/Documentation/devicetree/bindings/mips/gic.txt >>> b/Documentation/devicetree/bindings/mips/gic.txt >>> new file mode 100644 >>> index 0000000..725f1ef >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/mips/gic.txt >>> @@ -0,0 +1,50 @@ >>> +MIPS Global Interrupt Controller (GIC) >>> + >>> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins. >>> +It also supports a timer and software-generated interrupts which can be >>> +used as IPIs. >>> + >>> +Required properties: >>> +- compatible : Should be "mti,global-interrupt-controller" >>> +- reg : Base address and length of the GIC registers. >>> +- interrupts : Core interrupts to which the GIC may route external >>> interrupts. >> >> >> This doesn't make sense to me. The GIC can, and does, route interrupts to >> all CPU cores in a SMP system. How can there be a concept of only >> associating it with several interrupt lines on a single CPU in the system? >> That is not what the GIC does, is it? It is a Global interrupts controller, >> not local. So specifying device tree bindings that don't show its Global >> nature seems wrong. > > While the GIC can route external interrupts to any HW interrupt vector > it may not make sense to actually use all those vectors. For example, > the CP0 timer is usually hooked up to HW vector 5 (it could be treated > as a GIC local interrupt, though it may still be fixed to HW vector > 5). BTW, the Malta example about the i8259 I gave before was wrong - > it appears that it actually gets chained with the GIC. Your comments don't really make sense to me in the context of my knowledge of the GIC. Of course all the CP0 timer and performance counter interrupts are per-CPU and routed directly to the corresponding CP0_Cause[IP7..IP2] bits. We are don't need to give them further consideration. Here is the scenario you should consider: o 16 CPU cores. o 1 GIC routing interrupts from external sources to the 16 CPUs. o 2 network controllers each with an interrupt line routed to the GIC. Q: What would the GIC "interrupts" property look like? Note that the GIC doesn't have a single "interrupt-parent", as it can route interrupts to *all* 16 CPUs. I propose that the GIC have neither an "interrupt-parent", nor "interrupts". The fact that it is an "mti,global-interrupt-controller", means that the software drivers for the GIC already know how to route interrupts, and any information the device tree could contain is redundant. > > What would you suggest instead? Route all GIC interrupts to a single > vector? Yes. The OCTEON interrupt controllers although architecturally distinct, have many of the same features as the GIC, and this is what we do there. You could route the IPI interrupts to IP2, and device interrupts to IP3, or some similar arrangement. But the main point is that the hardware is very flexible in how the interrupt signals are routed. Somehow encoding a single simple and very restricted topology into the device-tree doesn't seem useful to me. It may be the case that only certain of the CP0_Cause[IP7..IP2] bits should be used by the GIC in a particular system (if they are used by timer or profiling hardware for example). If that is the case, then we would have to have some way to specify that. But it wouldn't be done via the "interrupts" property. > Attempt to distribute them over all 6 vectors? No. -- 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
On Tue, Sep 2, 2014 at 5:50 PM, David Daney <ddaney.cavm@gmail.com> wrote: > On 09/02/2014 12:36 PM, Andrew Bresticker wrote: >> >> On Tue, Sep 2, 2014 at 10:27 AM, David Daney <ddaney.cavm@gmail.com> >> wrote: >>> >>> On 08/29/2014 03:14 PM, Andrew Bresticker wrote: >>>> >>>> >>>> The Global Interrupt Controller (GIC) present on certain MIPS systems >>>> can be used to route external interrupts to individual VPEs and CPU >>>> interrupt vectors. It also supports a timer and software-generated >>>> interrupts. >>>> >>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org> >>>> --- >>>> Documentation/devicetree/bindings/mips/gic.txt | 50 >>>> ++++++++++++++++++++++++++ >>>> 1 file changed, 50 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/mips/gic.txt >>>> >>>> diff --git a/Documentation/devicetree/bindings/mips/gic.txt >>>> b/Documentation/devicetree/bindings/mips/gic.txt >>>> new file mode 100644 >>>> index 0000000..725f1ef >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/mips/gic.txt >>>> @@ -0,0 +1,50 @@ >>>> +MIPS Global Interrupt Controller (GIC) >>>> + >>>> +The MIPS GIC routes external interrupts to individual VPEs and IRQ >>>> pins. >>>> +It also supports a timer and software-generated interrupts which can be >>>> +used as IPIs. >>>> + >>>> +Required properties: >>>> +- compatible : Should be "mti,global-interrupt-controller" >>>> +- reg : Base address and length of the GIC registers. >>>> +- interrupts : Core interrupts to which the GIC may route external >>>> interrupts. >>> >>> >>> >>> This doesn't make sense to me. The GIC can, and does, route interrupts >>> to >>> all CPU cores in a SMP system. How can there be a concept of only >>> associating it with several interrupt lines on a single CPU in the >>> system? >>> That is not what the GIC does, is it? It is a Global interrupts >>> controller, >>> not local. So specifying device tree bindings that don't show its Global >>> nature seems wrong. >> >> >> While the GIC can route external interrupts to any HW interrupt vector >> it may not make sense to actually use all those vectors. For example, >> the CP0 timer is usually hooked up to HW vector 5 (it could be treated >> as a GIC local interrupt, though it may still be fixed to HW vector >> 5). BTW, the Malta example about the i8259 I gave before was wrong - >> it appears that it actually gets chained with the GIC. > > > Your comments don't really make sense to me in the context of my knowledge > of the GIC. > > Of course all the CP0 timer and performance counter interrupts are per-CPU > and routed directly to the corresponding CP0_Cause[IP7..IP2] bits. We are > don't need to give them further consideration. > > > Here is the scenario you should consider: > > o 16 CPU cores. > o 1 GIC routing interrupts from external sources to the 16 CPUs. > o 2 network controllers each with an interrupt line routed to the GIC. > > Q: What would the GIC "interrupts" property look like? > > Note that the GIC doesn't have a single "interrupt-parent", as it can route > interrupts to *all* 16 CPUs. > > I propose that the GIC have neither an "interrupt-parent", nor "interrupts". > The fact that it is an "mti,global-interrupt-controller", means that the > software drivers for the GIC already know how to route interrupts, and any > information the device tree could contain is redundant. Ok, I misunderstood your opposition to the binding. My intention for the "interrupt-parent" and "interrupts" property of the GIC was to express that GIC interrupts are routed to the CPU interrupt vectors and that a certain set of these vectors are available for use by the GIC. I would agree that these are mostly redundant (obviously the GIC routes interrupts to CPU interrupt vecotrs) and that it is not the most accurate description of the GIC-CPU relationship (the CPU interrupt controller are per-CPU, not global, and the GIC can route interrupts to any of them), though I'm not sure that there's a better way of describing it in DT. So that leaves us with something like this: interrupt-controller@1bdc0000 { compatible = "mti,global-interrupt-controller"; interrupt-controller; #interrupt-cells = <2>; available-cpu-vectors = <2>, <3>, ... }; DT folks, thoughts? -- 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
On 09/03/2014 04:53 PM, Andrew Bresticker wrote: > On Tue, Sep 2, 2014 at 5:50 PM, David Daney <ddaney.cavm@gmail.com> wrote: [...] >> >> Your comments don't really make sense to me in the context of my knowledge >> of the GIC. >> >> Of course all the CP0 timer and performance counter interrupts are per-CPU >> and routed directly to the corresponding CP0_Cause[IP7..IP2] bits. We are >> don't need to give them further consideration. >> >> >> Here is the scenario you should consider: >> >> o 16 CPU cores. >> o 1 GIC routing interrupts from external sources to the 16 CPUs. >> o 2 network controllers each with an interrupt line routed to the GIC. >> >> Q: What would the GIC "interrupts" property look like? >> >> Note that the GIC doesn't have a single "interrupt-parent", as it can route >> interrupts to *all* 16 CPUs. >> >> I propose that the GIC have neither an "interrupt-parent", nor "interrupts". >> The fact that it is an "mti,global-interrupt-controller", means that the >> software drivers for the GIC already know how to route interrupts, and any >> information the device tree could contain is redundant. > > Ok, I misunderstood your opposition to the binding. > > My intention for the "interrupt-parent" and "interrupts" property of > the GIC was to express that GIC interrupts are routed to the CPU > interrupt vectors and that a certain set of these vectors are > available for use by the GIC. I would agree that these are mostly > redundant (obviously the GIC routes interrupts to CPU interrupt > vecotrs) and that it is not the most accurate description of the > GIC-CPU relationship (the CPU interrupt controller are per-CPU, not > global, and the GIC can route interrupts to any of them), though I'm > not sure that there's a better way of describing it in DT. > > So that leaves us with something like this: > > interrupt-controller@1bdc0000 { > compatible = "mti,global-interrupt-controller"; > > interrupt-controller; > #interrupt-cells = <2>; > > available-cpu-vectors = <2>, <3>, ... Exactly what I had in mind, except for the missing "reg" property. This gives software the information it needs, but doesn't impose any policy. I will defer to others on the exact name the "available-cpu-vectors" should have. > }; > > DT folks, thoughts? > > -- 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
diff --git a/Documentation/devicetree/bindings/mips/gic.txt b/Documentation/devicetree/bindings/mips/gic.txt new file mode 100644 index 0000000..725f1ef --- /dev/null +++ b/Documentation/devicetree/bindings/mips/gic.txt @@ -0,0 +1,50 @@ +MIPS Global Interrupt Controller (GIC) + +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins. +It also supports a timer and software-generated interrupts which can be +used as IPIs. + +Required properties: +- compatible : Should be "mti,global-interrupt-controller" +- reg : Base address and length of the GIC registers. +- interrupts : Core interrupts to which the GIC may route external interrupts. +- interrupt-controller : Identifies the node as an interrupt controller +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt specifier. Should be 3. + - The first cell is the GIC interrupt number. + - The second cell encodes the interrupt flags. + See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid + flags. + - The optional third cell indicates which CPU interrupt vector the GIC + interrupt should be routed to. It is a 0-based index into the list of + GIC-to-CPU interrupts specified in the "interrupts" property described + above. For example, a '2' in this cell will route the interrupt to the + 3rd core interrupt listed in 'interrupts'. If omitted, the interrupt will + be routed to the 1st core interrupt. + +Example: + + cpu_intc: interrupt-controller@0 { + compatible = "mti,cpu-interrupt-controller"; + + interrupt-controller; + #interrupt-cells = <1>; + }; + + gic: interrupt-controller@1bdc0000 { + compatible = "mti,global-interrupt-controller"; + reg = <0x1bdc0000 0x20000>; + + interrupt-controller; + #interrupt-cells = <3>; + + interrupt-parent = <&cpu_intc>; + interrupts = <3>, <4>; + }; + + uart@18101400 { + ... + interrupt-parent = <&gic>; + interrupts = <24 IRQ_TYPE_LEVEL_HIGH 0>; + ... + };
The Global Interrupt Controller (GIC) present on certain MIPS systems can be used to route external interrupts to individual VPEs and CPU interrupt vectors. It also supports a timer and software-generated interrupts. Signed-off-by: Andrew Bresticker <abrestic@chromium.org> --- Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 Documentation/devicetree/bindings/mips/gic.txt