RFC: proposal to extend the open-pic interrupt specifierdefinition
Yoder Stuart-B08248
B08248 at freescale.com
Thu Jan 7 14:33:03 EST 2010
> -----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 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.
Stuart
More information about the devicetree-discuss
mailing list