[RFC PATCH 1/1] of/irq: create interrupts-extended-2 property

Grant Likely grant.likely at linaro.org
Fri Jan 24 12:39:55 EST 2014


On Mon, 20 Jan 2014 17:03:23 -0800, Olof Johansson <olof at lixom.net> wrote:
> On Mon, Jan 20, 2014 at 2:47 PM, Grant Likely <grant.likely at linaro.org> wrote:
> > On Wed, 15 Jan 2014 16:12:24 +0000, Mark Rutland <mark.rutland at arm.com> wrote:
> >> >
> >> > Another, more invasive option would be extend the dts syntax and teach
> >> > dtc to handle property appending. Then the soc dts could stay as it is,
> >> > and the board dts could have something like:
> >> >
> >> >     /append-property/ interrupts = <&intc1 6 1>;
> >> >     /append-property/ interrupt-names = "board-specific-irq";
> >> >
> >> > Both these options solve the issue at the source, are general to other
> >> > properties, and allow more than one level of hierarchy (the proposed
> >> > interrupts-extended-2 only allows one level).
> >>
> >> I've just had a go at implementing the append-property mechanism above
> >> in dtc, and it was far easier than I expected (patch below).
> >>
> >> Does anyone have any issues with the /append-property/ idea?
> >
> > I think that is reasonable.
> 
> 
> The main problem with this (same for clocks) is if you need to append
> something with a name when the original didn't have any.
> 
> Reordering entries might not work for interrupts, since the bindings
> might have requirements on order.

Hmmm, yes. to handle that case would need a higher level construct that
keeps the name and interrupt value together. Maybe something like this?

device {
	add-interrupt(27);
	add-interrupt(29, 5, controller=&intc1);
	add-interrupt(2, 4, name="error");
};

I'm using python-like syntax here where controller and name are optional
arguments.

We could get DTC to generate the appropriate interrupt-parent,
interrupts, interrupts-extended and interrupt-names properties as
needed. Of course the shared context would be lost when the tree is
compiled, but it would be useful for building up parsing data. It would
also work for gpio, clocks and similar bindings. Kind of like an
intelligent macro.

g.



More information about the linux-arm-kernel mailing list