On Tue, Sep 21, 2010 at 6:45 PM, Thomas Gleixner <t...@linutronix.de> wrote: > On Tue, 21 Sep 2010, Grant Likely wrote: >> On Tue, Sep 21, 2010 at 7:25 AM, Shaju Abraham <shaju.abra...@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. _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss