Hi Stephen,

On Sunday 20 October 2013 22:35:04 Stephen Warren wrote:

On 10/20/2013 01:41 PM, Laurent Pinchart wrote:

quoted

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

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

quoted

quoted

binding like this:

...

quoted

quoted

device@3000 {
	interrupts-extended = <&intc1 5> <&intc2 3 4> <&intc1 6>;
};

...

quoted

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.

Very good point. I agree with you, a new property is then better.

It seems much more flexible to use a new property and hence make it explicit
what format the data is in.

-- 
Regards,

Laurent Pinchart

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