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

[Yoder Stuart-B08248]

> -----Original Message-----
> From: glikely at secretlab.ca [mailto:glikely at secretlab.ca] On 
> Behalf Of Grant Likely
> Sent: Wednesday, January 13, 2010 12:04 AM
> To: Wood Scott-B07421
> Cc: David Gibson; Yoder Stuart-B08248; 
> devicetree-discuss at lists.ozlabs.org; parch at power.org; Gala 
> Kumar-B11780
> Subject: Re: [Power.org:parch] Re: RFC: proposal to extend 
> the open-pic interrupt specifierdefinition
> 
> On Thu, Jan 7, 2010 at 10:18 AM, Scott Wood 
> <scottwood at freescale.com> wrote:
> > David Gibson wrote:
> >>
> >> On Wed, Jan 06, 2010 at 08:33:03PM -0700, Yoder 
> Stuart-B08248 wrote:
> >>>
> >>> "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?
> >
> > The interrupt controller driver.
> >
> >> From what you've said here,
> >> I don't see why it needs to be in the interrupt specifiers.
> >
> > The case that this grew out of was the p4080 error 
> interrupt, which is
> > basically a cascaded interrupt controller within the mpic.  
All errors
> > arrive on the same mpic vector, but each has its own bit in 
> summary and mask
> > registers.  The subtype contains that bit number.
> >
> > It could also be used for expressing interrupts such as 
> IPIs and timers that
> > aren't part of the numbered interrupts that start at offset 0x10000.
> 
> If it really does behave as a cascaded irq, then give is a separate
> irq number space; either by a separate error-cascade interrupt
> controller node

We considered that-- treating this case as a separate interrupt
domain.  That starts getting really ugly in that a number of devices
will then have 2 interrupt controllers for the same device.  The
device tree does not support that nicely.  It requires creating
a interrupt-map under the device so that different interrupt
numbers can mapped to different interrupt controller.  It possible
but ugly.   Having numerous interrupt maps scattered around
under device nodes makes things must less human-readable and
less clear what is going on.

It also does not solve the problem of representing things
like the MPIC timers which do not behave as a cascaded
interrupt controller.

> or by choosing a new range of hw irq numbers outside
> of the current range handled by the mpic.

But where would the meaning of the new range live.  Yes, we
could pick interrupt numbers 2000-2032 to be error interrupts,
but we want to avoid hard coding assumptions like that
in the MPIC driver.

> It does not sound sane or
> particularly parseable to stuff it into bitfields within the second
> cell.

I think it is somewhat sane compared to the alternatives.  The
second cell encodes information about the interrupt source.  Allowing
some of those bits to encode information besides level/sense
doesn't seem that difficult.

> Users have enough trouble parsing irq specifiers as is.  It makes me
> nervous to see even more complicated irq specifiers being devised.

Yes, they become slightly more complicated, but the complexity needs to
go somewhere.

Stuart