Re: [PATCH] gpio: omap: fix irq triggering in smart-idle wakeup mode

From: santosh shilimkar
Date: Mon Apr 18 2016 - 20:02:08 EST


On 4/18/2016 4:36 PM, Tony Lindgren wrote:
* Grygorii Strashko <grygorii.strashko@xxxxxx> [160418 08:59]:
On 04/15/2016 09:54 PM, Tony Lindgren wrote:
* santosh shilimkar <santosh.shilimkar@xxxxxxxxxx> [160415 08:22]:
On 4/15/2016 2:26 AM, Grygorii Strashko wrote:

Santosh, Tony, do you want me to perform any additional actions regarding this patch?

This patch should be run across family of SOCs to make
sure wakeup works on all of those if not done already

Also, I'm not sure if we can just drop this code in question.

After this patch, what function updates the GPIO wkup_en registers
depending on enable_irq_wake()/disable_irq_wake()?


The main purpose of this patch is to *not* modify GPIO wkup_en registers
depending of enable_irq_wake()/disable_irq_wake() :), instead all
non wake up IRQs should be masked during suspend.

OK that makes sense.

The GPIO wkup_en registers should be always in sync with GPIO irq_en when
GPIO IP is in smart-idle wakeup mode. And this is done now from
omap_gpio_unmask_irq/omap_gpio_mask_irq(). See also [1].

In general, it is more or less similar to GIC + wakeupgen:
- during normal work (including cpuidle) GIC irq_en and Wakeupgen wkup_en
should be in sync always
- during suspend - only IRQs, marked as wake up sources, should be left
unmasked.

Also, I've found old thread [2] where Santosh proposed to use IRQCHIP_MASK_ON_SUSPEND.
And it was not possible, at that time, but now IRQCHIP_MASK_ON_SUSPEND can be used :),
because OMAP GPIO driver was switched to use generic irq handler instead of chained, so
now OMAP GPIO irqs are properly handled by IRQ PM core.
[chained irqs (and chained irq handles) are not disabled during suspend/resume and they are
not maintained by IRQ PM core as result they can trigger way too early on resume when
OMAP GPIO is not ready/powered.]

OK. For my tests this patch does not change anything. I noticed however
that we still have some additional bug somewhere where GPIO wake up
events work fine for omap3 PM runtime, but are flakey for suspend.

I've tested it on: am57x-evm, am437x-idk-evm, omap4-panda

OK thanks! Based on my tests and the above:

Acked-by: Tony Lindgren <tony@xxxxxxxxxxx>

If all works then consider my ack as well :-)