On Mon, 20 Jan 2014 17:03:23 -0800, Olof Johansson <olof@xxxxxxxxx> wrote:
> On Mon, Jan 20, 2014 at 2:47 PM, Grant Likely <grant.likely@xxxxxxxxxx> wrote:
> > On Wed, 15 Jan 2014 16:12:24 +0000, Mark Rutland <mark.rutland@xxxxxxx> 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.
--
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
