lkml.org 
[lkml]   [2010]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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.

    Thanks,

    tglx


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