"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 <le...@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@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@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev >
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
