Regarding hw irq to Linux irq mapping on ARM

[Grant Likely]

On Tue, Sep 21, 2010 at 6:45 PM, Thomas Gleixner <tglx at linutronix.de> wrote:
> On Tue, 21 Sep 2010, Grant Likely wrote:
>> On Tue, Sep 21, 2010 at 7:25 AM, Shaju Abraham <shaju.abraham at linaro.org> wrote:
>> > Hi Grant
>> >
>> > Since there does not exist a mechanism to map the hw irq to linux irq
>> > on ARM (device tree), I would like to discuss  with you the plans or
>> > ideas to implement the same.
>>
>> I don't have any immediate plans, but this topic has come up a lot in
>> the last two weeks, so I guess I need to focus on it.  :-)  [cc'ing
>> devicetree-discuss and linux-arm-kernel as well as Lorenzo and Eric
>> since this is a conversation that should be had publically]
>>
>> > Can you share with me your thoughts on it?
>> > I have browsed through the power pc code for the same. But not sure
>> > the same approach is usable on ARM as well.
>>
>> I haven't thought deeply about the powerpc implementation of virqs to
>> determine if it is suitable for other architectures or not, but the
>> concept behind it is sound.  We need a method of mapping controller
>> specific IRQ (or hw irq) numbers into the global Linux irq space
>> (referred to a virqs from this point on).  First it requires a
>> per-controller reference which can be a pointer to a per-controller
>> data structure, or any other unique identifier.  It could even be the
>> interrupt controller device tree node pointer.  Just so long as there
>> is a reliable method to derive the virq from the controller reference
>> + hw irq number.
>>
>> There also needs to be a method for each interrupt controller to
>> register itself and allocate a portion of the virq range.  This
>> shouldn't be too hard.  PowerPC handles this with the irq_map[] flat
>> table.  This approach is limited to whatever NR_IRQs is set to, and
>> could potentially be limited by that, but on the other hand the number
>> of discrete IRQ sources in a system is limited so a flat table
>> (instead of a dynamic hash table) is probably sufficient.  It is
>> certainly simpler to implement.
>>
>> I think the first step is to simply try generalizing the code in
>> arch/powerpc/kernel/irq.c.  It isn't very complex and it would give a
>> better impression of what needs to be done.  The ARM interrupt
>> controller drivers would need to be modified to register with the virq
>> infrastructure.  None of this is either ARM or OF specific; it would
>> be useful for any system than need to dynamically allocate IRQ
>> numbers.  I could see some x86 use cases (Xilinx FPGAs) where this
>> would be useful.
>
> Add all the I2C, SPI based irq extenders to that list. They seem to
> pop up all over the place in rapid speed even in x86. We are happy
> citizens of the embedded horror^Wuniverse now.

*shudder*

What's the irq handling latency on those?  Glad I haven't had to deal
with any of them yet.

g.