RFC: proposal to extend the open-pic interrupt specifier definition

[Yoder Stuart-B08248]

> -----Original Message-----
> From: 
> devicetree-discuss-bounces+stuart.yoder=freescale.com at lists.oz
labs.org [mailto:devicetree-discuss->
bounces+stuart.yoder=freescale.com at lists.ozlabs.org] On 
> Behalf Of Segher Boessenkool
> Sent: Tuesday, January 12, 2010 12:18 PM
> To: Yoder Stuart-B08248
> Cc: devicetree-discuss at lists.ozlabs.org; parch at power.org
> Subject: Re: RFC: proposal to extend the open-pic interrupt 
> specifier definition
> 
> > The current open-pic binding defines that interrupt specifiers
> > have 2 cells-- an interrupt number and level/sense encoding.
> >
> > With chips like the P4080 this is no longer sufficient to
> > represent the various types of interrupt sources handled by
> > the interrupt controller.  A linear list of interrupt numbers
> > doesn't handle all interrupt types-- there are at least 4 different
> > kinds of interrupts on the P4080.
> >
> > We have a proposal to extend the open-pic binding in
> > a backwards compatible way to encode additional information
> > in the level/sense field.
> 
> Why can you not have a particular "compatible" for your device,
> i.e. have a new binding for it?  Changing the "base" binding is
> asking for trouble.
> 
> You can of course base your binding on the openpic one.

Sure we can do that, but it is nice to standardize if possible to
avoid gratuitous different solutions solving the same problem.

> > The advantage of the above approach is backwards compatibility.
> > Existing interrupt specifiers (and device trees) are valid with
> > this proposal.
> 
> Actually they're not, like BenH pointed out.

The proposal is backwards compatible.  An existing interrupt
specifier  (e.g. interrupts = <24 2>;) retains its exact
same meaning.  Old device trees do not need to change
to comply with the proposal.

I'm not directly familiar with the case Ben pointed out, but
it sounded like Apple used the 1st cell in some non-standard
way.

It is true that openpic drivers would need to change to handle
the new specifier-- minimally masking the level/sense field
to 2 bits.

Stuart