On Mon, May 3, 2010 at 3:40 PM, Kevin Hilman
<khilman@xxxxxxxxxxxxxxxxxxx> wrote:
> Mike Chan <mike@xxxxxxxxxxx> 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 <mike@xxxxxxxxxxx>
>
> Thanks for moving this up to before the potential transition of PER.
>
> But...
>
>> ---
>> arch/arm/mach-omap2/pm34xx.c | 14 ++++++++++----
>> 1 files changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>> index ea0000b..2b2eaaa 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -371,6 +371,13 @@ void omap_sram_idle(void)
>> if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
>> pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
>>
>> + /* 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();
>> + }
>> +
>
> oops, both next_states will always be PWRDM_POWER_ON here as they
> haven't yet been read...
>
>> /* PER */
>> per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
>> core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
>
> until here.
Sloppy me, I'll send out a v2 that fixes this. Thanks Kevin for catching this.
-- Mike
>
> Kevin
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
