On Sat, 28 Feb 2009, David Brownell wrote: > That seems to presume a hardirq-to-taskirq handoff. But the > problem case is taskirq-to-taskirq chaining, through e.g. > what set_irq_chip_and_handler() provided. (Details not very > amenable to brief emails, just UTSL.) > > Thing is, I'm not sure a per-IRQ thread can work easily with > that chaining. The chained IRQs can need to be handled before > the top-level IRQ gets re-enabled. That's why the twl4030-irq > code uses just one taskirq thread for all incoming events. This can be solved by a completion as well. > (Which of course is rarely more than one at a time, so there's > little reason not to share that task between the demuxing code > and the events being demuxed. Interrupts that need processing > via I2C/SPI/etc are more or less by definition not frequent or > performance-critical.) Then all we need to provide in the generic code is a function which does not go through the handle_IRQ_event() logic and calls the action handler directly. Not rocket science to do that and better than using a facility which is designed to run in hardirq context and expect that it works in thread context without complaints. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
