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

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

[Soohyung Cho]

[-- Attachment #1: Type: text/plain, Size: 367 bytes --]

Hello.

I need to enable suspend-to-mem(deep sleep) on my mpc8349e-mitx-gp box.
When I send "mem" message to /sys/power/state, the box seems to get stop.
I think the box get stop when it executes suspend-asm.S codes.

I know that the latest linux supports suspend-to-mem on the mpc8313erdb box
well.
Is it impossible to enable suspend-to-mem on the mpc8349e-mitx-gp?

[-- Attachment #2: Type: text/html, Size: 408 bytes --]

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

[Li Yang-R58472]

> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Soohyung Cho
> Sent: Thursday, March 19, 2009 1:47 PM
> To: linuxppc-dev@ozlabs.org; Wood Scott-B07421
> Subject: suspend-to-mem on the mpc8349e-mitx-gp?
>=20
> Hello.
>=20
> I need to enable suspend-to-mem(deep sleep) on my=20
> mpc8349e-mitx-gp box.
> When I send "mem" message to /sys/power/state, the box seems=20
> to get stop.
> I think the box get stop when it executes suspend-asm.S codes.
>=20
> I know that the latest linux supports suspend-to-mem on the=20
> mpc8313erdb box well.
> Is it impossible to enable suspend-to-mem on the mpc8349e-mitx-gp?

I don't think the MPC8349 hardware has the deep sleep functionality.

- Leo

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

[Scott Wood]

On Thu, Mar 19, 2009 at 12:24:26AM -0700, Li Yang-R58472 wrote:
> > -----Original Message-----
> > From: linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org 
> > [mailto:linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org] 
> > On Behalf Of Soohyung Cho
> > Sent: Thursday, March 19, 2009 1:47 PM
> > To: linuxppc-dev@ozlabs.org; Wood Scott-B07421
> > Subject: suspend-to-mem on the mpc8349e-mitx-gp?
> > 
> > Hello.
> > 
> > I need to enable suspend-to-mem(deep sleep) on my 
> > mpc8349e-mitx-gp box.
> > When I send "mem" message to /sys/power/state, the box seems 
> > to get stop.
> > I think the box get stop when it executes suspend-asm.S codes.
> > 
> > I know that the latest linux supports suspend-to-mem on the 
> > mpc8313erdb box well.
> > Is it impossible to enable suspend-to-mem on the mpc8349e-mitx-gp?
> 
> I don't think the MPC8349 hardware has the deep sleep functionality.

However, the code should treat "mem" as "standby" on chips that don't
support deep sleep.  What does the device tree look like (the upstream
device tree for that board does not have any reference to the PMC)?  What
kernel are you using?

-Scott

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

[Li Yang-R58472]

> -----Original Message-----
> From: Wood Scott-B07421=20
> Sent: Friday, March 20, 2009 12:11 AM
> To: Li Yang-R58472
> Cc: Soohyung Cho; linuxppc-dev@ozlabs.org
> Subject: Re: suspend-to-mem on the mpc8349e-mitx-gp?
>=20
> On Thu, Mar 19, 2009 at 12:24:26AM -0700, Li Yang-R58472 wrote:
> > > -----Original Message-----
> > > From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
> > > [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org]
> > > On Behalf Of Soohyung Cho
> > > Sent: Thursday, March 19, 2009 1:47 PM
> > > To: linuxppc-dev@ozlabs.org; Wood Scott-B07421
> > > Subject: suspend-to-mem on the mpc8349e-mitx-gp?
> > >=20
> > > Hello.
> > >=20
> > > I need to enable suspend-to-mem(deep sleep) on my=20
> mpc8349e-mitx-gp=20
> > > box.
> > > When I send "mem" message to /sys/power/state, the box=20
> seems to get=20
> > > stop.
> > > I think the box get stop when it executes suspend-asm.S codes.
> > >=20
> > > I know that the latest linux supports suspend-to-mem on the=20
> > > mpc8313erdb box well.
> > > Is it impossible to enable suspend-to-mem on the mpc8349e-mitx-gp?
> >=20
> > I don't think the MPC8349 hardware has the deep sleep functionality.
>=20
> However, the code should treat "mem" as "standby" on chips=20
> that don't support deep sleep.  What does the device tree=20

Well, shouldn't the valid() callback reject unsupported states instead
of covering up?

- Leo

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

[Scott Wood]

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.

I'm willing to change it if there's substantial existing practice to the 
contrary, though.

-Scott

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

[Li Yang-R58472]

> -----Original Message-----
> From: Wood Scott-B07421=20
> 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?
>=20
> Li Yang-R58472 wrote:
> >> However, the code should treat "mem" as "standby" on chips=20
> that don't=20
> >> support deep sleep.  What does the device tree
> >=20
> > Well, shouldn't the valid() callback reject unsupported=20
> states instead=20
> > of covering up?
>=20
> I don't think so, in this case.  The user is not asking for=20
> "sleep" or deep sleep"; they are asking for a power state=20
> that meets the definition of "standby" (which sleep does) or=20
> which meets the definition of "mem"=20
> (which both sleep and deep sleep do).  When the user asks for=20
> "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

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

[MJ embd]

[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

"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@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
>

[-- Attachment #2: Type: text/html, Size: 2726 bytes --]

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

[Soohyung Cho]

[-- Attachment #1: Type: text/plain, Size: 1314 bytes --]

2009/3/23 Li Yang-R58472 <LeoLi@freescale.com>

> > -----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
>


I also agree to Leo.
It can be confusing, if "mem" means both sleep and deep sleep.
It would be better not to show "mem", if 8349 don't have deep sleep mode.

- Soohyung

[-- Attachment #2: Type: text/html, Size: 2005 bytes --]

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

[Scott Wood]

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

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

[Li Yang]

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

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

[Pavel Machek]

On Wed 2009-03-25 18:42:41, Li Yang wrote:
> On Tue, Mar 24, 2009 at 12:54 AM, Scott Wood <scottwood@freescale.com> wrote:
> > 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).
> 
> 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?

If you have single sleep state, use "mem" > /sys/power/state. 

If you have two, use mem and standby. Do you have more?

> >
> > 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

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Scott Wood]

Pavel Machek wrote:
>> Pavel, what's the preferred way for current PM sub-system?
> 
> If you have single sleep state, use "mem" > /sys/power/state. 
> 
> If you have two, use mem and standby. Do you have more?

Some of our chips have two, and some have one.  However, the sleep state 
of the chips that have only one is the same as the "standby" state of 
the chips that have two, not the "mem" state.  Accepting "mem" and only 
"mem" for the one-state chip seems like the most confusing of the 
options discussed.  There would be no consistent way for userspace to 
request the milder suspend state.

-Scott

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

[Pavel Machek]

On Wed 2009-03-25 11:31:57, Scott Wood wrote:
> Pavel Machek wrote:
>>> Pavel, what's the preferred way for current PM sub-system?
>>
>> If you have single sleep state, use "mem" > /sys/power/state. 
>>
>> If you have two, use mem and standby. Do you have more?
>
> Some of our chips have two, and some have one.  However, the sleep state  
> of the chips that have only one is the same as the "standby" state of  
> the chips that have two, not the "mem" state.  Accepting "mem" and
> only  

Ok, I guess it makes sense to use "standby" for the single sleep
state, then... It is not really a big deal, anyway.

> "mem" for the one-state chip seems like the most confusing of the  
> options discussed.  There would be no consistent way for userspace to  
> request the milder suspend state.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html