On Tue, 31 Jan 2012, Grazvydas Ignotas wrote: > 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? Probably. I think what's going on here is that you're hitting the hardwired sleep dependency between PER and CORE_L3. This is documented briefly in the 34xx TRM Rev. ZT in Section 4.8.5.1 "Sleep Dependencies". The PER clockdomain isn't allowed to go to sleep until the CORE_L3 clockdomain goes to sleep. Sounds like we may not be handling this correctly in the pm34xx.c code. As an aside, I've often thought that we should program the hardcoded sleep dependencies into the clockdomain data... > Maybe GPIO module ends up active but with debounce clock disabled? Well, whether it's in or out of idle, I'll bet the DEBOUNCENABLE bits are still set to 1 while the debounce clock is off :-( - Paul -- 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
