Re: Threaded interrupts for synaptic touchscreen in HTC dream

David Brownell
2009-07-22T22:09:17Z

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