On Tue, Jan 31, 2012 at 1:39 PM, Grazvydas Ignotas <notasas@xxxxxxxxx> wrote: > So when does all wakeup stuff come into effect, when CORE+PER go to > low power state? I'm using 3.2 and CORE seems to always be ON > (regardless of cpuidle option) except when I suspend I guess. I can > get PER state to change if I set serial timeouts, but that doesn't > help the GPIO problem. There is a strange thing in pm34xx.c, omap_sram_idle() function: I've added logging of per_next_state, and it's always 1 (PWRDM_POWER_RET) for me, however if I check /debug/pm_debug/count , core_pwrdm and per_pwrdm only has 1 for ON and zeros for all other states. That function calls gpio debounce clock disable if per_next_state < PWRDM_POWER_ON. Does that mean this code is preparing for RET but never enters it? Maybe GPIO module ends up active but with debounce clock disabled? -- Gražvydas -- 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
