RFC: proposal to extend the open-pic interrupt specifierdefinition

[Grant Likely]

On Thu, Jan 7, 2010 at 10:39 AM, Yoder Stuart-B08248
<B08248 at freescale.com> wrote:
>> > > 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.
>
> It is relevant to whatever code manages the interrupt
> controller.
>
> A bit more background information. The MPIC in Freescale chips
> supports several types of interrupts-- SOC devices, external
> interrupts, MSIs, timers.   The registers to manage these interrupt
> sources are not laid out in a way that is conducive to just enumerating
> all the interrupt sources starting from zero.   They are in different
> discrete areas of the MPIC register map.
>
> We need the device tree to be able to represent all interrupt sources
> and distinguish between timer interrupt 0 and SOC device interrupt
> 0 and MSI interrupt 0.

Sounds to me that it would be far more sane to either use cascaded
interrupt nodes to handle these different irq number spaces, or to use
multiple cells for the hw irq number.  Trying to encode these things
into bit fields in the second cell sounds like trouble and confusion
to me, not to mention premature optimization to reduce the number of
cells being used per IRQ.

Oh, and *DOCUMENT THE HELL OUT OF IT*.  Give uses an easy reference to
figure out what the irq specifier needs to be for the device they're
using.  I had enough trouble from the MPC5200's 2 level irq number
scheme in this regard.  The confusion finally went away (mostly) when
I stopped trying to describe to everyone how it worked and instead
specifically documented that IRQ1 == <0 0 x>, IRQ2 == <1 1 x>, IRQ3 ==
<1 2 x>, IRQ4 == <1 3 x>.  :-)

g.

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