On Tue, Jul 21, 2009 at 01:49:33PM +0100, Mark Brown wrote:

On Tue, Jul 21, 2009 at 06:00:07PM +0530, Trilok Soni wrote:

quoted

Hopefully, this thread can give all details about threaded irq discussion.

quoted

http://lkml.org/lkml/2009/2/27/255

Yes, I'm aware of that - I read it at the time.  It seemed to peter out
without any satisfactory solution, unfortunately.  There's two separate
issues here:

 - 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
   hardirq context to disable the interrupt if it's level triggered but
   most of the time the only option they've got is to disable the IRQ
   and reenable it when the worker thread is done.  This is the issue
   here.

   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.

 - 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.

I've added the folks from Samsung posting the MELFAS MCS-5000 driver to
the thread since they're running into the same issue.

Let's also add Thomas and David since I believe they worked on the
feature.

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.

-- 
Dmitry