[lkml]   [2010]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Mon, 31 May 2010, James Bottomley wrote:

> On Mon, 2010-05-31 at 22:49 +0200, Thomas Gleixner wrote:
> > On Sat, 29 May 2010, James Bottomley wrote:
> > > The job of the kernel is to accommodate hardware as best it can ...
> > > sometimes it might not be able to, but most of the time it does a pretty
> > > good job.
> > >
> > > The facts are that C states and S states are different and are entered
> > > differently.
> >
> > That's an x86'ism which is going away. And that's really completely
> > irrelevant for the mobile device space. Can we please stop trying to
> > fix todays x86 based laptop problems? They are simply not fixable.
> You're the one mentioning x86, not me. I already explained that some
> MSM hardware (the G1 for example) has lower power consumption in S3
> (which I'm using as an ACPI shorthand for suspend to ram) than any
> suspend from idle C state.

Those machines can go from idle into S2RAM just fine w/o touching the
/sys/power/state S2RAM mechanism.

It's just a deeper "C" state, really.

The confusion is that S3 is considered to be a complete different
mechanism - which is true for PC style x86 - but not relevant for
hardware which is sane from the PM point of view.

Now some people think, that suspend blockers are a cure for the
existing x86/ACPI/BIOS mess, which cannot go to S3 from idle, but
that's simply not feasible.



 \ /
  Last update: 2010-06-01 00:19    [W:0.279 / U:2.352 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site