On Tue, Jul 21, 2009 at 10:30:26PM +0200, Thomas Gleixner wrote: > On Tue, 21 Jul 2009, Dmitry Torokhov wrote: > > On Tue, Jul 21, 2009 at 01:49:33PM +0100, Mark Brown wrote: > > > - Ordinary devices on interrupt driven or slow buses like I2C. These > > > need something along the lines of request_threaded_irq() that's allows > > > them to schedule the main IRQ handler outside hardirq context so > > > that they can interact with the device. They need to do something in > There is already a sane solution to the problem: > See http://lkml.org/lkml/2009/7/17/174 I'll need to have a more detailed look at that but it's not immediately clear to me how a driver (or even machine) should use that code - it looks more like it's intended to be called from within the IRQ infrastructure than from random driver code. > > > My immediate thought when I noticed this was that we should probably > > > fix request_threaded_irq() so that it's useful for them; I'd been > > > intending to do some digging and try to understand why it is > > > currently implemented as it is. > What's to fix there ? Nothing if the above works, though I guess more documentation wouldn't hurt (and possibly a more friendly wrapper). From the name and documentation request_threaded_irq() looks like it should be exactly what's needed. > > > - Multi-function devices like the twl4030 which have an interrupt > > > controller on them and would like to expose that interrupt controller > > > via the generic IRQ subsystem. This was a large part of the > > > discussion in the thread above is a much trickier problem. > Why ? Partly just because it's idiomatic for the devices - these things are from a software point of view essentially a small stack of devices glued together and one of the devices on them is an interrupt controller so the natural thing is to want to represent that interrupt controller in the way Linux normally represents interrupt controllers and be able to reuse all the core code rather than having to implement a clone of it. The other part of it is that it gets you all the interfaces for interrupts that the rest of the kernel expects which is needed when the device interacts with others. The biggest issue here is that these devices often have GPIOs on them (especially PMICs and audio CODECs). These have all the facilities one expects of GPIOs, including being used as interrupt sources. If we need to use chip-specific APIs to interact with the interrupts they raise then the drivers for anything using them need to know about those APIs and have special cases to work with them which obviously doesn't scale. > > >From my part I would like to have the threaded IRQ available to all > > drivers since it seens to be hanlding driver shutdown cleanly and > > without races which is a big plus for me since very few drivers get it > > right. > :) It's also wasteful having to write the code in every single driver that needs to handle interrupts on interrupt driven buses. -- 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
