Re: suspend-to-mem on the mpc8349e-mitx-gp?

[Li Yang <leoli@freescale.com>]

On Tue, Mar 24, 2009 at 12:54 AM, Scott Wood <scottwood@freescale.com> wrot=
e:
> On Sun, Mar 22, 2009 at 10:45:23PM -0700, Li Yang-R58472 wrote:
>> > I don't think so, in this case. =C2=A0The user is not asking for
>> > "sleep" or deep sleep"; they are asking for a power state
>> > that meets the definition of "standby" (which sleep does) or
>> > which meets the definition of "mem"
>> > (which both sleep and deep sleep do). =C2=A0When the user asks for
>> > "mem", we provide the lowest power mode that qualifies.
>>
>> In my understanding, "mem" which is suspend-to-ram means all CPU states
>> and registers are kept in memory and the CPU is completely off during
>> suspension. =C2=A0I don't think the sleep mode of 8349 qualifies, does i=
t?
>
> Is there a difference visible to software or to the user (other than not
> achieving power savings that the board does not support)? =C2=A0It seems
> simpler for userspace to just specify the "heaviest" sleep state it wants
> deal with (though some feedback to an administrator of what actually
> happens would be nice).

I agree that it's handy to have a "sleep" state in kernel to
automatically enter the "heaviest" sleep state supported.  However it
is also very simple for user space script or application to check the
available states first and then enter explicitly the "heaviest" sleep
state.

Pavel, what's the preferred way for current PM sub-system?

- Leo

>
> And if we want to be really pedantic, neither sleep nor deep sleep meet
> the definitions for either "standby" or "mem", because they specify
> acceptable latency ranges in seconds, and (in the absence of a disk) we
> are much faster than that (it doesn't say "up to 1-2 seconds"). :-)
>
> Are there any existing suspend drivers that suppord standby but not mem?
> I see omap1 as a counterexample that treats them both the same.
>
> -Scott