omap: pm34xx: Enable IO / IO-CHAIN wakeups for PER
PATCH 1/2 omap: pm34xx: Enable IO / IO-CHAIN wakeups for PER
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.
--- arch/arm/mach-omap2/pm34xx.c | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-)
arch/arm/mach-omap2/pm34xx.c +8 -2
@@ -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 (); }
Signature · 1 line
1.7.0.1
PATCH 2/2 omap: pm34xx: Remove PER wakeup dependency on CORE.
We can remove this wakeup dependency since now, when GPIO2-6 are enabled for IO-pad wakeup, PER domain is gauranteed to be awake or be woken up to service.
The previous dependency did not handle all corner cases. Since there was no sleep dependency between CORE and PER domains, if PER enters RET and CORE is ON, PER will not be active for GPIO handling.
--- arch/arm/mach-omap2/pm34xx.c | 8 -------- 1 files changed, 0 insertions(+), 8 deletions(-)
arch/arm/mach-omap2/pm34xx.c +0 -8
@@ -1086,14 +1086,6 @@ static int __init omap3_pm_init(void)omap3_idle_init ();clkdm_add_wkdep (neon_clkdm, mpu_clkdm); -/* -* REVISIT: This wkdep is only necessary when GPIO2-6 are enabled for -* IO-pad wakeup. Otherwise it will unnecessarily waste power -* waking up PER with every CORE wakeup - see -* http://marc.info/?l=linux-omap&m=121852150710062&w=2 -*/ -clkdm_add_wkdep (per_clkdm, core_clkdm); -if (omap_type () !=OMAP2_DEVICE_TYPE_GP ) { omap3_secure_ram_storage =kmalloc (0x803F ,GFP_KERNEL );
Signature · 1 line
1.7.0.1
Quoted 6 lines · Mike Chan
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 <[email protected]>
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
Quoted 7 lines · Kevin Hilman
Quoted 5 lines · Mike Chan
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.
Quoted 7 lines
Quoted 1 line
Signed-off-by Mike Chan <[email protected]>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.
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 wakeup if PER or CORE goes into RET solve this.
Quoted 2 lines
I need to dig a little more in the TRM on this one to clarify.
I was looking at 4.11.2.2 I/O Wake-Up Mechanism (pg 421)
Quoted 4 lines
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'
I will check to see if we have somethign mis-configured.
-- Mike
Quoted 4 lines
Kevin
Quoted 22 lines · Mike Chan
Quoted 7 lines · Kevin Hilman
Quoted 5 lines · Mike Chan
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.
Quoted 7 lines
Quoted 1 line
Signed-off-by Mike Chan <[email protected]>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.
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 wakeup if PER or CORE goes into RET solve this.
Quoted 5 lines
Quoted 2 lines
I need to dig a little more in the TRM on this one to clarify.
I was looking at 4.11.2.2 I/O Wake-Up Mechanism (pg 421)
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
Quoted 41 lines · Kevin Hilman
Quoted 22 lines · Mike Chan
Quoted 7 lines · Kevin Hilman
Quoted 5 lines · Mike Chan
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.
Quoted 7 lines
Quoted 1 line
Signed-off-by Mike Chan <[email protected]>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.
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 wakeup if PER or CORE goes into RET solve this.
Quoted 5 lines
Quoted 2 lines
I need to dig a little more in the TRM on this one to clarify.
I was looking at 4.11.2.2 I/O Wake-Up Mechanism (pg 421)
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."
Quoted 9 lines
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.
Sounds good, I'll spin a v2 and send it out.
-- Mike
Quoted 7 lines
Kevin
Quoted 6 lines
From: linux-omap-owner at vger.kernel.org [mailto:linux-omap- owner at vger.kernel.org] On Behalf Of Kevin Hilman
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.
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.