[PATCH] RFC: interrupt consistency check for OF GPIO IRQs
From: Stephen Warren <hidden>
Date: 2013-10-20 21:35:19
Also in:
linux-devicetree, linux-omap, lkml
On 10/20/2013 01:41 PM, Laurent Pinchart wrote:
Hi Grant, On Tuesday 17 September 2013 17:36:32 Grant Likely wrote:quoted
On Thu, 12 Sep 2013 17:57:00 +0200, Alexander Holler wrote:quoted
Am 12.09.2013 17:19, schrieb Stephen Warren:quoted
IRQs, DMA channels, and GPIOs are all different things. Their bindings are defined independently. While it's good to define new types of bindings consistently with other bindings, this hasn't always happened, so you can make zero assumptions about the IRQ bindings by reading the documentation for any other kind of binding. Multiple interrupts are defined as follows: // Optional; otherwise inherited from parent/grand-parent/... interrupt-parent = <&gpio6>; // Must be in a fixed order, unless binding defines that the // optional interrupt-names property is to be used. interrupts = <1 IRQF_TRIGGER_HIGH> <2 IRQF_TRIGGER_LOW>; // Optional; binding for device defines whether it must // be present interrupt-names = "foo", "bar"; If you need multiple interrupts, each with a different parent, you need to use an interrupt-map property...
...
quoted
Actually, I think it is solveable but doing so requires a new binding for interrupts. I took a shot at implementing it earlier this week and I've got working patches that I'll be posting soon. I created a new "interrupts-extended" property that uses a phandle+args type of binding like this:
...
quoted
device at 3000 { interrupts-extended = <&intc1 5> <&intc2 3 4> <&intc1 6>; };
...
Any progress on this ? I'll need to use multiple interrupts with different parents in the near future, I can take this over if needed. I've also been thinking that we could possibly reuse the "interrupts" property without defining a new "interrupts-extended". When parsing the property the code would use the current DT bindings if an interrupt-parent is present, and the new DT bindings if it isn't.
interrupt-parents doesn't have to be present in individual nodes; it can be inherited from the parent. That means you'd have to convert whole sub-trees at once. It seems much more flexible to use a new property and hence make it explicit what format the data is in.