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

[Sethi Varun-B16395]

> -----Original Message-----
> From: parch at power.org [mailto:parch at power.org] On Behalf Of 
> David Gibson
> Sent: Thursday, January 07, 2010 10:25 AM
> To: Yoder Stuart-B08248
> Cc: devicetree-discuss at lists.ozlabs.org; parch at power.org
> Subject: [Power.org:parch] 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.
> 
Error interrupt case would be relevant for a hypervisor in a virtual
environment. Hypervisor may have to virtualize access to a paltform
error register.

-Varun