Grant Likely wrote:
On Wed, Jan 13, 2010 at 7:19 AM, Yoder Stuart-B08248
<[email protected]> wrote:
It does not sound sane or
particularly parseable to stuff it into bitfields within the second
cell.
I think it is somewhat sane compared to the alternatives. The
second cell encodes information about the interrupt source. Allowing
some of those bits to encode information besides level/sense
doesn't seem that difficult.
Not difficult. Ugly, unnecessary, and sounds like a premature optimization.
It is not optimization, but functionality.
Users have enough trouble parsing irq specifiers as is. It makes me
nervous to see even more complicated irq specifiers being devised.
Yes, they become slightly more complicated, but the complexity needs to
go somewhere.
Then at the very least do it as separate cells. Carving cells into
multiple fields is pretty ugly when cells are cheap.
That means that all the interrupt specifiers in an existing tree have to
be updated with the larger numer of cells whenever such an interrupt is
added, since #interrupt-cells applies globally to the MPIC interrupt
domain. It's unnecessary churn.
-Scott
_______________________________________________
devicetree-discuss mailing list
[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
