Re: lockdep and threaded IRQs (was: ...)
From: David Brownell
Date: Sat Feb 28 2009 - 01:17:57 EST
On Friday 27 February 2009, Andrew Morton wrote:
> On Fri, 27 Feb 2009 20:46:50 -0800 David Brownell <david-b@xxxxxxxxxxx> wrote:
> > drivers/mfd/twl4030-irq.c
> > Where you'll observe twl_init_irq() at line 688 setting
> > up the thread and the Primary IRQ Handler (PIH) dispatch.
> > That's pretty much bog-standard chained IRQ setup code,
> > except that it chains through a thread.
> OK, that's clever. I never knew that anyone was doing that. afaict
> MFD is the only such place...
This is the Mark II code, which can look clever
because it uses genirq better than the fairly
ugly Mark I code (and doesn't clone the same
logic into three separate drivers).
What's unique about this particular code is that
it chains those IRQs, instead of creating its own
little irq core (like menelaus.c in that directory)
or only needing to handle one IRQ (as with RTC
> Yes, it's regrettable that it's a private-to-mfd implementation.
More like: private-to-twl4030. If a more generic
version (Mark III) comes along at some point, I'd
hope switching would be easy...
> I expect a lot of i2c clients (at least) would like this.
I2C, SPI, maybe some more ... yes. RTC alarm handling,
as one fairly routine example.
> Perhaps it would be somewhat less dirty to do something like
Yeah, that #ifdef is pretty ugly.
Thomas sent some threaded IRQ patches around sometime
last fall, which handled the top level dispatch but
ISTR not the chaining part. This kind of thing would
be appropriate for the chained IRQs. Maybe the flag
would better be named IRQF_THREADED.
(However, this flavor hack wouldn't address the lockdep
breakage for drivers like the AT91 and OMAP1 MMC hosts.)
> --- a/kernel/irq/manage.c~a
> +++ a/kernel/irq/manage.c
> @@ -689,7 +689,8 @@ int request_irq(unsigned int irq, irq_ha
> * Lockdep wants atomic interrupt handlers:
> - irqflags |= IRQF_DISABLED;
> + if (!(irqflags & IRQF_NO_LOCKDEP_HACK))
> + irqflags |= IRQF_DISABLED;
> * Sanity-check: shared interrupts must pass in a real dev-ID,
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/