Re: Threaded interrupts for synaptic touchscreen in HTC dream

[David Brownell <david-b@pacbell.net>]

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