From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by ozlabs.org (Postfix) with ESMTP id D8EF8DDEEB for ; Mon, 23 Mar 2009 17:17:20 +1100 (EST) Received: by qw-out-2122.google.com with SMTP id 9so877860qwb.15 for ; Sun, 22 Mar 2009 23:17:18 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <3A45394FD742FA419B760BB8D398F9ED2FA48E@zch01exm26.fsl.freescale.net> References: <3A45394FD742FA419B760BB8D398F9ED29EB95@zch01exm26.fsl.freescale.net> <49C3AB35.4080700@freescale.com> <3A45394FD742FA419B760BB8D398F9ED2FA48E@zch01exm26.fsl.freescale.net> Date: Mon, 23 Mar 2009 15:17:18 +0900 Message-ID: Subject: Re: suspend-to-mem on the mpc8349e-mitx-gp? From: Soohyung Cho To: Li Yang-R58472 , scottwood@freescale.com, linuxppc-dev@ozlabs.org Content-Type: multipart/alternative; boundary=0015175ce0e4eb5d2f0465c33762 List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --0015175ce0e4eb5d2f0465c33762 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 2009/3/23 Li Yang-R58472 > > -----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 --0015175ce0e4eb5d2f0465c33762 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0=A0
2009/3/23 Li Yang-R58472 <<= a href=3D"mailto:LeoLi@freescale.com">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 t= he mpc8349e-mitx-gp?
>
> Li Yang-R58472 wrote:
> >> However, the = code should treat "mem" as "standby" on chips
> t= hat don't
> >> support deep sleep. =A0What does the device = tree
> >
> > Well, shouldn't the valid() callback reject unsu= pported
> states instead
> > of covering up?
>
>= I don't think so, in this case. =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). =A0When the user asks for
> "mem"= , we provide the lowest power mode that qualifies.

In my understanding, "mem" which is suspend-to-ram mean= s all CPU states and registers are kept in memory and the CPU is completely= off during suspension. =A0I don't think the sleep mode of 8349 qualifi= es, does it?

- Leo
=A0

I also agree to Leo.
It can be confusing, if "mem" means both sleep and deep slee= p.
It would be better not to show=A0"mem", if 8349 don't ha= ve deep sleep mode.
=A0
- Soohyung
--0015175ce0e4eb5d2f0465c33762--