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

MJ embd mj.embd at gmail.com
Mon Mar 23 17:16:38 EST 2009


"fsl,mpc8349-pmc" has .has_deep_sleep = 0, deep_sleeping=0 so the mem
should not do anything and just do a standby.

I am not sure if mem is a valid state in that case under /sys/power/state.

Scott, u can fix it!

-mj


On Mon, Mar 23, 2009 at 11:15 AM, Li Yang-R58472 <LeoLi at freescale.com>wrote:

> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, March 20, 2009 10:42 PM
> > To: Li Yang-R58472
> > Cc: Soohyung Cho; linuxppc-dev at ozlabs.org
> > Subject: Re: suspend-to-mem on the mpc8349e-mitx-gp?
> >
> > Li Yang-R58472 wrote:
> > >> However, the code should treat "mem" as "standby" on chips
> > that don't
> > >> support deep sleep.  What does the device tree
> > >
> > > Well, shouldn't the valid() callback reject unsupported
> > states instead
> > > of covering up?
> >
> > 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?
>
> - Leo
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20090323/3e3a12ed/attachment.htm>


More information about the Linuxppc-dev mailing list