Re: Question regarding suspend/resume

[Kevin Hilman <khilman@ti.com>]

Peter Barada <peter.barada@gmail.com> 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