Messages in this thread |  | | Date | Sat, 28 Feb 2009 12:48:23 +0100 | | From | Stefan Richter <> | | Subject | Re: lockdep and threaded IRQs |
| |
David Brownell wrote: > Now, where is that being set up as being threaded? I > referenced that a message or two earlier: > > 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. > > When an IRQ comes in, handle_twl4030_pih() acks and masks > that top level IRQ. Then it wakes twl4030_irq_thread(), > which issues I2C operations to read the IRQ status from > the chip ... first PIH to find out which SIH modules are > raising an IRQ, then SIH to dispatch that status. Then > handle_irq() from that thread to invoke the handler in > that thread context; it will issue more I2C ops. > > And the lockdep thing kicks in through handle_irq(), > where the IRQ handler wrongly gets invoked with the > IRQs disabled -- iff lockdep is enabled. Otherwise, > that IRQ thread is just like any other thread.
Ah, so there /is/ a threaded IRQ handler implementation in the mainline, down in some driver framework...
Why don't these drivers simply use <linux/workqueue.h>? -- Stefan Richter -=====-==--= --=- ===-- http://arcgraph.de/sr/
|  |