> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > David Gibson > Sent: Thursday, January 07, 2010 10:25 AM > To: Yoder Stuart-B08248 > Cc: [email protected]; [email protected] > 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: > > > [email protected] > > labs.org [mailto:devicetree-discuss-> > > [email protected]] On > > > Behalf Of David Gibson > > > Sent: Wednesday, January 06, 2010 6:51 PM > > > To: Yoder Stuart-B08248 > > > Cc: [email protected]; [email protected] > > > 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 _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
