[PATCH] nmk-gpio: use request_irq instead of chained handler
From: Rabin Vincent <hidden>
Date: 2011-02-23 15:22:07
On Wed, Feb 23, 2011 at 18:48, Russell King - ARM Linux [off-list ref] wrote:
On Wed, Feb 23, 2011 at 06:24:50PM +0530, Rabin Vincent wrote:quoted
__nmk_gpio_irq_handler doesn't do anything more that what a normal handler does, so it can become one. ?This is also needed for changing the GIC implementation to a different flow handler.So you want to allow other people to request the GPIO interrupt?
No, but we request it without IRQF_SHARED so why would other people be able to do so? If they had done it before, there will be an error here.
You also want to have the IRQ tracing code called once for entry into this handler and once for each GPIO interrupt which is pending?
Because the GPIO interrupts come via a different parent interrupt (the secondary handler stuff) when in certain low power states, it may be useful to see which parent the interrupt comes from. Not a deal breaker though.
You want to have the overhead of dealing with the inprogress stuff, etc? I really don't like the idea of getting rid of the interrupt chaining and reverting back to the proven-to-be-broken 2.2 kernel way of handing this kind of thing - which is exactly what you're doing here.
I thought it was the recommendation in the other thread to have chained interrupts that do nothing but the normal irq handling to just use that. With the GIC fasteoi change we will anyway not have the interrupt being masked. The secondary irq handler chip uses handle_simple_irq so that should be OK too. Anyway, I guess there's no strong reason to drop the chained handler, and we can do without any unnecessary overheads so I will just preserve the chained handler and do only the eoi here (along with the GIC conversion).