Re: 2.6.29 PM and CPUIDLE

[Kevin Hilman <khilman@deeprootsystems.com>]

Jean Pihet <jpihet@mvista.com> writes:

> I am having problems using CPUIDLE PM_SLEEP on Beagleboard with the
> latest pm tree.  It looks like CPUIDLE prevents the system to go
> into retention mode, while it works fine without CPUIDLE enabled:

It's a feature. ;)

> root@beagleboard:~# echo 1 > /sys/power/clocks_off_while_idle
> root@beagleboard:~# echo mem > /sys/power/state

Try this:

# echo 1 > /sys/power/sleep_while_idle

And then try to suspend.  I think this should work (you may have to
wait a little just so you hit the idle loop before trying suspend.)

What's happening is that without sleep_while_idle set, CPUidle will
not go into any other state than C1 (see the omap3_can_sleep() check.)
Recently, C1 was changed to keep the MPU and CORE ON to have the a
very fast wakeup latency.  So, with CPUidle running, the next power
states are set to ON in the idle path and never tested/changed in the
suspend path.

The bug is that the suspend path should always ensure that either RET
or OFF is set in the next states (depending on enable_off_mode.)  This
was not necessary before the new C1 was added because all of the idle
states at least tried for RET.

Kevin

> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.02 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> Suspending console(s) (use no_console_suspend to debug)
> omapfb omapfb: timeout waiting for FRAME DONE
> Powerdomain (core_pwrdm) didn't enter target state 1
> Powerdomain (dss_pwrdm) didn't enter target state 1
> Could not enter target state in pm_suspend
> Restarting tasks ... done.
>
> The registers dump shows the next power state in PM_PWSTCTRL is set to ON 
> instead of RET for MPU and CORE. Furthermore DSS is not reaching RET (stays 
> ON).
>
> Are the CPUIDLE and suspend/resume features compatible with each other? Am I 
> missing something, e.g. a way to change the behavior from /sys?
>
> Regards,
> Jean