On Wednesday 22 July 2009, Thomas Gleixner wrote: > Ok, so let me summarize what we came up with so far. > > 1) handle_level_oneshot_irq is the correct answer to the problem of > those "I'm behind a slow bus" interrupt controllers. Where "slow" means "access needs to sleep" ... preventing register access from hardirq contexts. I think you must mean "IRQ source" not controller; in the examples so far on this thread, the irq_chip in these cases has been a typical SoC/ASIC thing, but the device issuing the IRQ is over I2C/etc. (When the irq_chip itself is across I2C/etc, #3 applies.) > 2) Some mechanism to request ONESHOT from the driver level is > required. Preferrably via a flag on request_threaded_irq Preferably "explicit"; a flag implementation suffices. Yes. > 3) a function which allows to express the nested thread irq nature of > the interrupt controller and its subdevices. That's one possible implementation. Basically, irq chaining should work for threaded IRQs; some irq_chip devices will be across sleeping/slow busses. Some will even chain to another level of irq_chip across such a bus. > 4) a generic serializing mechanism which is implemented via irq_chip > functions to solve the chip->mask/unmask issue for the demultiplexed > interrupts. Something like the bus_lock/bus_sync_unlock patch I posted > earlier. In general, all irq_chip methods would need to use the sleeping/slow bus ... like set_type(), and more. That patch somewhat resembles the twl4030_sih_irq_chip stuff. > 5) a common function which allows to call the thread handler of the > subdevice interrupts in the context of the main thread which takes > care of serialization against disable/enable/request/free irq et al. A mechanism like that, yes. ISTR sending a patch a while back with a handle_threaded_irq() flow handler which you'd suggested. I can dig that up if you like, but I suspect you've had more thoughts about it since that time. > Any more ? Not that comes quickly to mind. If genirq can do all that, then a lot of drivers/mfd/twl4030-irq.c can vanish ... I mention that as probably the strongest "acceptance test" that's handy. If you like to work with concrete use cases, that's one. Also, a simpler "slow irq_chip" device is the mcp23s08 GPIO expander. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
