Peter Barada <peter.barada@xxxxxxxxx> writes: > Is there any reference how to decode the output of > /debug/pm_debug/count? I'm trying to figure out when I resume why it > says the core_pwrdm didn't enter the target state, and I'm assuming > because a clock used is not disabled in the suspend path, but as fars > as I can tell there's no output in the pm_debug code that tells which > clocks in a power domain are active at the time of a suspend. You're right. What you need the patch in my pm-wip/debug branch from my pm tree[1]. With that patch, it takes a snapshot of the PRCM registers just before and after suspend. When you come back from suspend, view the register snapshot just before suspend: # cat /debug/pm_debug/register/1 and the register snapshot just after # cat /debug/pm_debug/register/2 the snapshot just before suspend is useful for debugging problems like yours, and the snapshot just after can be useful for debugging wakeups. Feel free to post the register dump if you want some help deciphering it. If you do, please post more details on what kernel you're using as well as the bootloader etc. One of the common root causes for a problem like yours is a bootloader that leaves a particular module in a state that it cannot properly idle. If the kernel is not using that particular device and/or has not reset that device, the result is the powerdomain for that device can not hit idle and you'll have a problem like yours. Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git -- 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
