On Tue, 12 Nov 2013 08:58:15 +1000, Peter Crosthwaite <peter.crosthwaite@xxxxxxxxxx> wrote: > Hi Grant, > > On Wed, Oct 16, 2013 at 6:39 AM, Grant Likely <grant.likely@xxxxxxxxxx> wrote: > > The standard interrupts property in device tree can only handle > > interrupts coming from a single interrupt parent. If a device is wired > > to multiple interrupt controllers, then it needs to be attached to a > > node with an interrupt-map property to demux the interrupt specifiers > > which is confusing. It would be a lot easier if there was a form of the > > interrupts property that allows for a separate interrupt phandle for > > each interrupt specifier. > > > > This patch does exactly that by creating a new interrupts-extended > > property which reuses the phandle+arguments pattern used by GPIOs and > > other core bindings. > > > > Signed-off-by: Grant Likely <grant.likely@xxxxxxxxxx> > > Cc: Rob Herring <rob.herring@xxxxxxxxxxx> > > --- > > .../bindings/interrupt-controller/interrupts.txt | 29 +++++++-- > > arch/arm/boot/dts/testcases/tests-interrupts.dtsi | 16 +++++ > > arch/arm/boot/dts/versatile-ab.dts | 2 +- > > arch/arm/boot/dts/versatile-pb.dts | 2 +- > > drivers/of/irq.c | 16 +++-- > > drivers/of/selftest.c | 70 ++++++++++++++++++++++ > > 6 files changed, 122 insertions(+), 13 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt > > index 72a06c0..1486497 100644 > > --- a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt > > +++ b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt > > @@ -4,16 +4,33 @@ Specifying interrupt information for devices > > 1) Interrupt client nodes > > ------------------------- > > > > -Nodes that describe devices which generate interrupts must contain an > > -"interrupts" property. This property must contain a list of interrupt > > -specifiers, one per output interrupt. The format of the interrupt specifier is > > -determined by the interrupt controller to which the interrupts are routed; see > > -section 2 below for details. > > +Nodes that describe devices which generate interrupts must contain an either an > > +"interrupts" property or an "interrupts-extended" property. These properties > > +contain a list of interrupt specifiers, one per output interrupt. The format of > > +the interrupt specifier is determined by the interrupt controller to which the > > +interrupts are routed; see section 2 below for details. > > + > > + Example: > > + interrupt-parent = <&intc1>; > > + interrupts = <5 0>, <6 0>; > > > > The "interrupt-parent" property is used to specify the controller to which > > interrupts are routed and contains a single phandle referring to the interrupt > > controller node. This property is inherited, so it may be specified in an > > -interrupt client node or in any of its parent nodes. > > +interrupt client node or in any of its parent nodes. Interrupts listed in the > > +"interrupts" property are always in reference to the node's interrupt parent. > > + > > +The "interrupts-extended" property is a special form for use when a node needs > > +to reference multiple interrupt parents. Each entry in this property contains > > +both the parent phandle and the interrupt specifier. "interrupts-extended" > > +should only be used when a device has multiple interrupt parents. > > + > > + Example: > > + interrupts-extended = <&intc1 5 1>, <&intc2 1 0>; > > + > > A slightly different but related problem I am trying to solve with > interrupt bindings, is to describe connection of a single device > interrupt line to multiple interrupts controller, whereas this binding > seems to be describing connection of different interrupt lines to > different controllers. Can this syntax accommodate my case is any way? > > Bascially I think I'm asking for multiple interrupt specifiers for a > single IRQ output if that's possible. > > Should I just be using the interrupt map syntax instead? > > interrupt-map-mask = < 0 0 63>; > interrupt-map = < 0 0 25 &intc0 ... >, < 0 0 25 &intc1 ... >, Interrupt map doesn't actually help you here either since the core code doesn't know what to do with it. It will probably only match and return one of the options. What I would do is describe both in your interrupts property and make the driver know that the extra interrupt specifier is for the same interrupt output. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
