Re: Threaded interrupts for synaptic touchscreen in HTC dream

[Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>]

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.