On Wed, Sep 22, 2010 at 1:31 PM, Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > On Wed, 2010-09-22 at 00:08 -0300, Grant Likely wrote: >> > 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. > > And i2c in many cases want to be called from sleep'able context... might > be a good idea to restrict some of these to threaded interrupts. A whole > different discussion I suppose. >
My problem is that ARM has only one IRQ line, and normally connected to a SoC specific IRQ controller, the mapping of the controller status bits into the linux IRQ number is currently handled in an assembly macro for performance consideration. This can be changed to using a function pointer for when mutliple SoCs are compiled [1]. All the other IRQs are actually chained to these first level IRQ numbers, so the other question is how these can be properly mapped. Currently, most ARM platforms handle this in board level. Taking an example of I2C GPIO expander pca953x.c, there is a 'irq_base' field in its platform data, this value could be different from board to board, and the board setup code has the responsibility to get it right. Other devices having a resource can be passed the correct IRQ number in its resource array. My understanding is that this simplest scheme should work in most cases, the assumption here is that the board setup code knows how to handle the IRQs, i.e. how many IRQs are used, and how they are actually mapped. The only requirement is that those external chip driver with IRQ capability are sanely written with dynamic configuration of its IRQ base and number. [1] http://www.spinics.net/lists/arm-kernel/msg88817.html. > Cheers, > Ben. > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
