On Tue, Sep 2, 2014 at 2:33 AM, Mark Rutland [off-list ref] wrote:

On Tue, Sep 02, 2014 at 01:53:18AM +0100, Andrew Bresticker wrote:

quoted

On Mon, Sep 1, 2014 at 4:01 AM, Mark Rutland [off-list ref] wrote:

quoted

On Fri, Aug 29, 2014 at 11:14:30PM +0100, Andrew Bresticker wrote:

quoted

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 <redacted>
---
 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.

quoted

quoted

quoted

+- 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.

quoted

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?

quoted

quoted

quoted

+- 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.

quoted

quoted

quoted

+  - 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html