IO events can also come from GPIO modules, which reside in the PER domain.
It is possible for the PER to enter RET while CORE is still in ON.
If GPIO 2-6 are enabled for IO-pad wakeups, the PER domain will not
wakeup in this case, unless we enable it.

Signed-off-by: Mike Chan <mike@android.com>
---
 arch/arm/mach-omap2/pm34xx.c |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index ea0000b..4ef322a 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -398,10 +398,15 @@ void omap_sram_idle(void)
 			omap3_core_save_context();
 			omap3_prcm_save_context();
 		}
-		/* Enable IO-PAD and IO-CHAIN wakeups */
+	}
+
+	/* Enable IO-PAD and IO-CHAIN wakeups */
+	if (per_next_state < PWRDM_POWER_ON ||
+			core_next_state < PWRDM_POWER_ON) {
 		prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
 		omap3_enable_io_chain();
 	}
+
 	omap3_intc_prepare_idle();
 
 	/*
@@ -463,7 +468,8 @@ void omap_sram_idle(void)
 	}
 
 	/* Disable IO-PAD and IO-CHAIN wakeup */
-	if (core_next_state < PWRDM_POWER_ON) {
+	if (per_next_state < PWRDM_POWER_ON ||
+			core_next_state < PWRDM_POWER_ON) {
 		prm_clear_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
 		omap3_disable_io_chain();
 	}
-- 
1.7.0.1

--

[ message continues ]

Hi Mike,

I'm a little puzzled on this one.  My understanding is that the IO pad
is only armed when CORE is in RET or OFF.

I need to dig a little more in the TRM on this one to clarify.

If CORE is staying on, it might be that your GPIO module level wakeups
are not being configured correctly.  Please check the 'Known Problems'
section of the OMAP PM wiki[1], search for 'GPIO module-level wakeups'

Kevin

[1] http://elinux.org/OMAP_Power_Management#Known_Problems
--

[ message continues ]

On Wed, Apr 21, 2010 at 5:07 PM, Kevin Hilman

The issue we are seeing is when the device is active but idle, if CORE
is ON and PER is in RET and the omap is sitting in swfi. If the user
presses a keypad button, IO pad doesn't wake us out of idle. Setting a


I will check to see if we have somethign mis-configured.

--

[ message continues ]

Yeah, that's the right place.

After a little more digging and asking around, this looks like a good
fix, but there's a minor problem with the implementation:

In the section of the TRM you referenced the following sentence is
hiding:

  "Software must wait for the I/O daisy chain to complete before it
   transitions the PER domain to a nonfunctional state."

In the proposed patch, it's likely that PER could transition to
INACTIVE/RET/OFF before the IO wakeups are enabled.  For example, if
nothing in PER is active except UART3, then PER will transition to an
idle state right after omap_uart_prepare_idle(2), which is before
the IO wakeups are currently enabled.

To be perfectly safe, the IO wakeups should be enabled before PER is
allowed to transition.

Kevin





--

[ message continues ]

On Thu, Apr 22, 2010 at 3:31 PM, Kevin Hilman

Sounds good, I'll spin a v2 and send it out.

--

[ message continues ]

For ES3 and before the io ring wake was 'armed' when ever core went to idle.  When core power state changed accounting was done for state.

This scheme created a small time window where per wake events could be lost in handoff from gpio to io daisy chain when targeting chip off.

In ES3.1 the EN_IO_CHAIN bit was added as a way to cover this hole.  It allows enabling the wake up daisy chain in software prior to idling core.  The trm does detail the exact steps.

The 3.1 bug fix covered the transition window observed going to chip states but probably can cover here.  I'm not sure about the patch as applied with studying.

Regards,
Richard W.

--

[ message continues ]