On Saturday 28 February 2009, Thomas Gleixner wrote: > > needs to run in a thread as well. Usually demux handlers just have a > > fast path kicking the particular real handlers. > > I looked at the code in twl4030-irq.c and I don't think that the demux > handler needs to be setup as a chained handler at all. > > Just register it as a standard handler and let it wakeup the other irq > threads Not clear what you mean by that. Did I miss a "wakeup an irq thread" operation? You've coupled the task to the irqaction, not to the irq_desc. > or is there a particular requirement that the demuxed handlers > need to run in the same thread context as the demux handler itself ? The toplevel IRQ shouldn't be re-enabled until all the chained handlers have actually handled their events ... some of those events are level triggered too. That needs synchronization, and the simplest synch is to just process those demuxed events in the same thread. The TWL4030 family chips are a little bit quirky with respect to IRQ handling (PIH vs SIH, SIH_CTRL.COR inconsistency, etc), but they aren't the only chips with such requirements for their internal IRQ controllers. - Dave -- 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
