[PATCH] gpio: zynq: Implement irq_(request|release)_resources
From: Linus Walleij <hidden>
Date: 2015-10-27 16:23:35
Also in:
linux-gpio, lkml
On Tue, Oct 27, 2015 at 5:18 PM, Grygorii Strashko [off-list ref] wrote:
On 10/27/2015 05:53 PM, Linus Walleij wrote:quoted
On Fri, Oct 23, 2015 at 3:36 PM, Soren Brinkmann [off-list ref] wrote:quoted
The driver uses runtime PM to leverage low power techniques. For use-cases using GPIO as interrupt the device needs to be in an appropriate state. Reported-by: John Linn <redacted> Signed-off-by: Soren Brinkmann <redacted> Tested-by: John Linn <redacted>As pointed out by Grygorii in commit aca82d1cbb49af34b69ecd4571a0fe48ad9247c1: The PM runtime API can't be used in atomic contex on -RT even if it's configured as irqsafe. As result, below error report can be seen when PM runtime API called from IRQ chip's callbacks irq_startup/irq_shutdown/irq_set_type, because they are protected by RAW spinlock: (...) The IRQ chip interface defines only two callbacks which are executed in non-atomic contex - irq_bus_lock/irq_bus_sync_unlock, so lets move PM runtime calls there. I.e. these calls are atomic context and it's just luck that it works and this is fragile. Can you please check if you can move it to irq_bus_lock()/irq_sync_unlock() like Grygorii does?This patch rises the question not only about PM runtime, but also about gpiochip_irq_reqres()/gpiochip_irq_relres().
Do you mean that these functions contain calls to non-atomic functions? I mainly reacted to this because it was pm_* calls, that you mentioned explicitly in your patch. Yours, Linus Walleij