RFC: proposal to extend the open-pic interrupt specifierdefinition

[David Gibson]

On Wed, Jan 06, 2010 at 08:33:03PM -0700, Yoder Stuart-B08248 wrote:
> > 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 David Gibson
> > Sent: Wednesday, January 06, 2010 6:51 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 
> > specifierdefinition
> > 
> > On Tue, Jan 05, 2010 at 04:28:12PM -0700, Yoder Stuart-B08248 wrote:
> > > 
> > > 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.
> > > 
> > > The current definition of level/sense is:
> > >   0 = low to high edge sensitive type enabled
> > >   1 = active low level sensitive type enabled
> > >   2 = active high level sensitive type enabled
> > >   3 = high to low edge sensitive type enabled
> > > 
> > > Those 2 bits would retain their current meaning, but the
> > > full encoding would be extended as follows:
> > > 
> > >      bits      meaning
> > >      ----------------------------------------------
> > >      0-7       interrupt sub-type
> > >      8-15      interrupt type
> > >      16-23     implementation dependent
> > >      24-29     reserved
> > >      30-31     level/sense encoding
> > 
> > Um.. what do "type" and "sub-type" mean in this context?
> 
> "type" specifies the type of interrupt-- example timer, MSI,
> etc and would define the meaning of the interrupt number
> portion of the interrupt specifier.   A given "type" may or
> may not have a "subtype" depending on the binding.
> 
> As described in the proposal, "type" is a range of numbers,
> divided between standard/architected types and implementation
> specific types.
> 
> We (Freescale) have at least one interrupt type "error" in the P4080
> that would have a "sub-type" that would indicate a related bit in
> another
> status register.

And who is the type/subtype relevant to?  From what you've said here,
I don't see why it needs to be in the interrupt specifiers.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson