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

[Grant Likely]

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, or by choosing a new range of hw irq numbers outside
of the current range handled by the mpic.  It does not sound sane or
particularly parseable to stuff it into bitfields within the second
cell.

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

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.