On Tue, Jul 21, 2009 at 06:00:07PM +0530, Trilok Soni wrote: > Hopefully, this thread can give all details about threaded irq discussion. > 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. -- 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