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