Hi Tony, >Just printing the registers out in the idle loop most likely will give >you the info you need. Probably a dumb question... But if I try to print them won't it automatically wakes up the serial (by the way should the serial wakeup be configured to RX pin only ?) Another thing I don't understand... Can it be that there is some ongoing kernel process that also prevent me for entering retention ? I think maybe I should try first to suspend (instead of trying to enter retention in idle) , maybe it might bring better result ? Thanks very much, Ran On Mon, Nov 17, 2014 at 10:38 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > * Ran Shalit <ranshalit@xxxxxxxxx> [141117 11:48]: >> >You need to look if you have some devices blocking deeper >> >idle states in cm_idlest*_core and cm_idlest_per registers. >> >> >The device will automatically idle whatever it can if there >> >are no blockers. I believe at least EHCI still is blocking, >> >and MUSB if configured and cable connected. >> >> I'll check the registers value, should I then try to modify this >> registers in order to get into retention ? > > No, those are read-only status registers. You need idle the > drivers that show as blocking in those registers. > >> I will still have to disable serial right ? Maybe some kernel process >> which run in background prevents retention ? > > Yes otherwise the UART bits will show as blocking in those > registers. > >> Is there some simple way to debug this or do I need to modify these registers ? > > Just printing them out in the idle loop most likely will give > you the info you need. > > Regards, > > Tony -- 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
