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]>
---
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
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.
Signed-off-by: Mike Chan <[email protected]>
---
arch/arm/mach-omap2/pm34xx.c | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 4ef322a..176870f 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -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);
--
1.7.0.1
Mike Chan <[email protected]> writes:
> 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
[1] http://elinux.org/OMAP_Power_Management#Known_Problems
On Wed, Apr 21, 2010 at 5:07 PM, Kevin Hilman
<[email protected]> wrote:
> Mike Chan <[email protected]> writes:
>
>> 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.
>
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.
> 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)
> 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
> Kevin
>
> [1] http://elinux.org/OMAP_Power_Management#Known_Problems
>
> From: [email protected] [mailto:linux-omap-
> [email protected]] 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.
Mike Chan <[email protected]> writes:
> On Wed, Apr 21, 2010 at 5:07 PM, Kevin Hilman
> <[email protected]> wrote:
>> Mike Chan <[email protected]> writes:
>>
>>> 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.
>>
>
> 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.
>
>> 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
On Thu, Apr 22, 2010 at 3:31 PM, Kevin Hilman
<[email protected]> wrote:
> Mike Chan <[email protected]> writes:
>
>> On Wed, Apr 21, 2010 at 5:07 PM, Kevin Hilman
>> <[email protected]> wrote:
>>> Mike Chan <[email protected]> writes:
>>>
>>>> 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.
>>>
>>
>> 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.
>>
>>> 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.
>
Sounds good, I'll spin a v2 and send it out.
-- Mike
> Kevin
>
>
>
>
>
>