On Monday 02 March 2009, Ingo Molnar wrote:
> >
> > The significant omission is lack of support for chaining
> > such threads. Example, an I2C device that exposes
> > several dozen IRQs with mask/ack/... operations that
> > require I2C access.
>
> Well, those are rarely used, embedded-only constructs - the main
> focus of IRQ threading patches are the more common patterns.
Yes, mostly for embedded, where "system bus" more likely
means I2C than PCI.
> Since you care about them - could you please send patches on top
> of the IRQ threading patches to add support for them?
I'll look at that, and try to prepare something on top
of the version of the threading patches that gets into
the -next tree. I got the impression there was going
to be a v3 of those patches soonish...
I expect there will be two basic parts of that work:
- One to cope with the upcoming change to handle_irq(),
insisting that it live in hardirq context instead of
just an irqs-off context (and thereby preventing use
of standard chaining calls in irq threads, sigh).
- Another to set up a chaining thread, since chain
setup bypasses setup_irq() and friends.
That latter might touch what the v2 patches added,
since I'd want it to share code.
- Dave
p.s. Note that those changes would still leave the
lockdep bug around ... it will still be breaking
various drivers that use normal IRQs, by forcibly
enabling IRQF_DISABLED.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
