Re: [Power.org:parch] Re: RFC: proposal to extend the open-pic interrupt specifierdefinition

[Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>]

Grant Likely wrote:
> On Wed, Jan 13, 2010 at 10:23 AM, Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
>> Grant Likely wrote:
>>> On Wed, Jan 13, 2010 at 7:19 AM, Yoder Stuart-B08248
>>> <B08248-KZfg59tc24xl57MIdRCFDg@public.gmane.org> 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.
> 
> I don't doubt you need the data.  What I object to is stuffing it all
> into a single cell since I think it is an unneeded optimization that
> also makes it less user friendly.

I'm fine with four cells (int config type subtype) if that's the 
consensus -- it's hard to guess in advance what will go over well.  User 
friendliness can be subjective.

>>>>> 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.
> 
> Pish.  You're talking about updating the interrupt properties in each
> affected .dts file, and it only needs to be done when the new binding
> is applied.  It will simply be adding a bunch of '0' cells to the
> beginning of each existing interrupts property in the file.

More likely the end -- putting it at the beginning *will* break existing 
code and require software to know which binding it is dealing with.

And don't forget interrupt-maps (which are hard enough to read as is, 
due to too many cells with no delimiters of logical groupings), or 
interrupts properties with more than one interrupt.

> Easy to
> review, not a hard change to make, and easier to use/understand
> binding for a long time to come.  BTW, how many .dts files do we
> really have in the tree right now that will be using the new binding?

One that will need it, and a bunch of others that might want to use it 
either to describe things like MPIC timers or message register 
interrupts, or to be able to share device tree source fragments with 
newer chips if that effort ever gets revived.

-Scott