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

Scott Wood scottwood at freescale.com
Tue Mar 24 03:54:02 EST 2009


On Sun, Mar 22, 2009 at 10:45:23PM -0700, Li Yang-R58472 wrote:
> > I don't think so, in this case.  The 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).  When 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.  I don't think the sleep mode of 8349 qualifies, does it?

Is there a difference visible to software or to the user (other than not
achieving power savings that the board does not support)?  It 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).  

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



More information about the Linuxppc-dev mailing list