On Wed, Dec 23, 2009 at 9:29 PM, Mark Brown
[off-list ref] wrote:
On Wed, Dec 23, 2009 at 12:18:25PM +0100, Marc Zyngier wrote:
quoted
On Wed, 23 Dec 2009 03:35:57 -0500
Haojian Zhuang [off-list ref] wrote:
quoted
On Tue, Dec 22, 2009 at 2:59 PM, Marc Zyngier [off-list ref] wrote:
quoted
[Putting Mark Brown in the loop, as wm831x is the de-facto reference]
Guys, could you please remember to cut unneeded context from replies?
quoted
quoted
set_irq_nested_thread(irq, 1) will only mark IRQ_NESTED_THREAD on irq
descriptor. It results that driver have to invoke request_thread_irq()
with thread_fn parameter to declare IRQ. Device could be linked to
GPIO directly or GPIO expander. We should keep to use request_irq()
for compatible. set_irq_nested_thread() shouldn't use at here.
quoted
While I fully understand your point, I'm more worried about the
correctness of the approach. I'm under the impression that the use of
IRQ_NESTED_THREAD is mandatory if we're using a threaded handler.
quoted
@Mark Brown: what is your take on this? Is it possible to use
generic_handle_irq() from within a threaded handler?
ICBW but I believe you'll find that you get into trouble with lockdep if
try to do that - the TWL4030 drivers in current mainline jump through
some hoops in the client drivers as a result of this if you want to look
at some examples. ?Once you're in a threaded IRQ you're in a slightly
different context and need to take account of that.
So do you mean that we should disable IRQ in the threaded IRQ context?
To the extent that this proves to be a problem in practical systems it's
something that needs to be addressed in the genirq core rather than
trying to jump through hoops in the individual drivers. ?Trying to work
around the genirq core is likely to be fragile for both the interrupt
controller driver and the client drivers trying to use it.