Re: ASoC related suspend problems on OMAP3

[Peter Ujfalusi <peter.ujfalusi@ti.com>]

On 02/08/2012 02:34 AM, Grazvydas Ignotas wrote:
> Hi,
> 
> On OMAP3 pandora, system suspend stops working properly after using
> audio at least once:
> 
> (just after boot):
> # echo mem > /sys/power/state
> [   12.578186] PM: Entering mem sleep
> [   12.678802] PM: suspend of devices complete after 92.834 msecs
> [   12.688201] PM: late suspend of devices complete after 3.173 msecs
> [   17.607971] Successfully put all powerdomains to target state
> 
> # aplay /dev/zero
> ^C
> # echo mem > /sys/power/state
> [  104.404663] PM: suspend of devices complete after 78.794 msecs
> [  104.413909] PM: late suspend of devices complete after 3.021 msecs
> [  106.601196] Powerdomain (per_pwrdm) didn't enter target state 1
> [  106.607421] Powerdomain (core_pwrdm) didn't enter target state 1
> [  106.613739] Could not enter target state in pm_suspend
> 
> I'm seeing this on 3.2, unable to verify on current Linus HEAD as
> something else is preventing core/per low power states there.
> Any ideas what could be causing this? Perhaps some clock is left enabled?

I would bet that some clocks left enabled, but it as far as I can tell
the audio path is well balanced in regards of clocks.

So I'm not sure, but I just checked with 3.3-rc2 on Beagle xM (Rev C):

after boot:
# echo mem > /sys/power/state
[  163.776153] Freezing user space processes ...
[  163.804595] (elapsed 0.02 seconds) done.
[  163.808746] Freezing remaining freezable tasks ... (elapsed 0.02 seconds)
[  163.837097] Suspending console(s) (use no_console_suspend to debug)
[  164.019042] PM: suspend of devices complete after 157.684 msecs
[  164.025115] PM: late suspend of devices complete after 6.011 msecs
[  164.025238] Disabling non-boot CPUs ...
[  172.497528] Successfully put all powerdomains to target state

aplay <some wav>

# echo mem > /sys/power/state
[  300.574920] Freezing user space processes ...
[  300.602874] (elapsed 0.02 seconds) done.
[  300.607025] Freezing remaining freezable tasks ... (elapsed 0.02 seconds)
[  300.635620] Suspending console(s) (use no_console_suspend to debug)
[  300.809692] PM: suspend of devices complete after 149.810 msecs
[  300.814117] PM: late suspend of devices complete after 4.364 msecs
[  300.814147] Disabling non-boot CPUs ...
[  309.520721] Successfully put all powerdomains to target state

Here it seams to be OK...
You could try to compare the clock counts after boot, and after the aplay:

cat /sys/kernel/debug/clock/summary

if they differ we leave have unbalanced clock handling...

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html