On Wed, 22 Jul 2009, David Brownell wrote: > On Wednesday 22 July 2009, Peter Zijlstra wrote: > > Wouldn't it be better if we could express the nesting property from > > within genirq, so that we can do things like: > > > > register_chip_nested(parent_chip, parent_irq, slave_chip); > > > > And let genirq set-up the needed magic to make the nesting work. > > I've been requesting such IRQ chaining support for some time > now ... if the ears are now listening, that kind of direction > should be pursued. Well, I was all ear back then, but the disconnect between "embedded only needs X be happy" and my repsonsibility to keep that all working for everyone was way larger. :) > > Also, how important is it that subhandler1..n run in their own thread? > > Completely unimportant in a practical sense. Undesirable, even; > wasteful to allocate all those stack pages and keep them idle > most of the time. > > There might be an argument that the design isn't technicaly done > until that model *can* be supported. On the flip side, last time > this came up there was no "customer demand" for that ... it was > all "supplier push". > > > > That is, can't we let them run from the thread that is otherwise waiting > > for the completino anyway? > > That would be far preferable, yes. 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. 2) Some mechanism to request ONESHOT from the driver level is required. Preferrably via a flag on request_threaded_irq 3) a function which allows to express the nested thread irq nature of the interrupt controller and its subdevices. 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. 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. Any more ? Thanks, tglx
