RFC: proposal to extend the open-pic interrupt specifierdefinition

[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 David Gibson
> Sent: Wednesday, January 06, 2010 10:55 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 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.

It is relevant to whatever code manages the interrupt
controller.

A bit more background information. The MPIC in Freescale chips
supports several types of interrupts-- SOC devices, external 
interrupts, MSIs, timers.   The registers to manage these interrupt
sources are not laid out in a way that is conducive to just enumerating
all the interrupt sources starting from zero.   They are in different
discrete areas of the MPIC register map.

We need the device tree to be able to represent all interrupt sources
and distinguish between timer interrupt 0 and SOC device interrupt
0 and MSI interrupt 0.

In the P4080 we have additional complexity in that SOC device
interrupt 0 is error interrupt that has multiple sources of
errors ORed into it.   We don't want to hardcode knowlege of the
specific topography of the error interrupts into software and
want to represent in the dev tree.

Stuart