Re: [PATCH 03/12] of: Add binding document for MIPS GIC
On 09/03/2014 04:53 PM, Andrew Bresticker wrote:
On Tue, Sep 2, 2014 at 5:50 PM, David Daney 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@1bdc {
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 linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
On Tue, Sep 2, 2014 at 5:50 PM, David Daney wrote:
> On 09/02/2014 12:36 PM, Andrew Bresticker wrote:
>>
>> On Tue, Sep 2, 2014 at 10:27 AM, David Daney
>> 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
---
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 000..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@1bdc {
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 linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
On Tue, Sep 2, 2014 at 5:50 PM, David Daney ddaney.c...@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.c...@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 abres...@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 000..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@1bdc {
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 linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
On 09/03/2014 04:53 PM, Andrew Bresticker wrote:
On Tue, Sep 2, 2014 at 5:50 PM, David Daney ddaney.c...@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@1bdc {
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 linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
On 09/02/2014 12:36 PM, Andrew Bresticker wrote: On Tue, Sep 2, 2014 at 10:27 AM, David Daney 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 --- 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 000..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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
On Tue, Sep 2, 2014 at 10:27 AM, David Daney 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 >> --- >> 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 000..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 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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
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
---
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 000..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 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@1bdc {
+ compatible = "mti,global-interrupt-controller";
+ reg = <0x1bdc 0x2>;
+
+ interrupt-controller;
+ #interrupt-cells = <3>;
+
+ interrupt-parent = <_intc>;
+ interrupts = <3>, <4>;
+ };
+
+ uart@18101400 {
+ ...
+ interrupt-parent = <>;
+ interrupts = <24 IRQ_TYPE_LEVEL_HIGH 0>;
+ ...
+ };
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
On Tue, Sep 2, 2014 at 2:33 AM, Mark Rutland 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 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
>> >> ---
>> >> 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 000..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 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@1bdc {
>> ...
>> interrupts = <3>, <4>;
>> ...
>> };
>>
>> uart {
>> ...
>> interrupt-parent = <>;
>> interrupts = <24 IRQ_TYPE_LEVEL_HIGH 1>;
>> ...
>> };
>>
>> i2c {
>> ...
>> interrupt-parent = <>;
>> 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
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
On Tue, Sep 02, 2014 at 01:53:18AM +0100, Andrew Bresticker wrote:
> On Mon, Sep 1, 2014 at 4:01 AM, Mark Rutland 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
> >> ---
> >> 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 000..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 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@1bdc {
> ...
> interrupts = <3>, <4>;
> ...
> };
>
> uart {
> ...
> interrupt-parent = <>;
> interrupts = <24 IRQ_TYPE_LEVEL_HIGH 1>;
> ...
> };
>
> i2c {
> ...
> interrupt-parent = <>;
> 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
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
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.rutl...@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 abres...@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 000..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@1bdc {
...
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
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
On Tue, Sep 2, 2014 at 2:33 AM, Mark Rutland mark.rutl...@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.rutl...@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 abres...@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 000..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@1bdc {
...
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
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
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 abres...@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 000..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@1bdc {
+ compatible = mti,global-interrupt-controller;
+ reg = 0x1bdc 0x2;
+
+ 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 linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
On Tue, Sep 2, 2014 at 10:27 AM, David Daney ddaney.c...@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 abres...@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 000..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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
On 09/02/2014 12:36 PM, Andrew Bresticker wrote: On Tue, Sep 2, 2014 at 10:27 AM, David Daney ddaney.c...@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 abres...@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 000..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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
On Mon, Sep 1, 2014 at 4:01 AM, Mark Rutland 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
>> ---
>> 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 000..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 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@1bdc {
...
interrupts = <3>, <4>;
...
};
uart {
...
interrupt-parent = <>;
interrupts = <24 IRQ_TYPE_LEVEL_HIGH 1>;
...
};
i2c {
...
interrupt-parent = <>;
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 linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
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
> ---
> 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 000..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 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@1bdc {
> + compatible = "mti,global-interrupt-controller";
> + reg = <0x1bdc 0x2>;
> +
> + interrupt-controller;
> + #interrupt-cells = <3>;
> +
> + interrupt-parent = <_intc>;
> + interrupts = <3>, <4>;
> + };
> +
> + uart@18101400 {
> + ...
> + interrupt-parent = <>;
> + 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 majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
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 abres...@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 000..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@1bdc {
+ compatible = mti,global-interrupt-controller;
+ reg = 0x1bdc 0x2;
+
+ 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
On Mon, Sep 1, 2014 at 4:01 AM, Mark Rutland mark.rutl...@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 abres...@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 000..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@1bdc {
...
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 linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
On Sat, Aug 30, 2014 at 12:53 AM, Arnd Bergmann 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 >> --- >> 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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
On Sat, Aug 30, 2014 at 12:53 AM, Arnd Bergmann a...@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 abres...@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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
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 > --- > 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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
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 abres...@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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
