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

> For some omap hardware, the power consumption in the
> lowest C state (with all the ancillary power control) is the same as S3,
> that's fine, suspend from idle works as well as suspend to ram modulo
> bad apps. For quite a lot of MSM hardware, the lowest C state power
> consumption is quite a bit above S3. It's not acceptable to tell those
> people "tough, your battery runs out in 30 minutes because you bought
> the wrong hardware". We have to figure out how to get to S3 ... whether
> this is from idle or some other mechanism is again a discussion point,
> but not doing it is not an option.

If you'd have read the answers from Alan carefully, then you'd have
noticed that even x86 hardware is getting to the point where OMAP is
today. i.e. support of transparent suspend from idle. If that wouldn't
happen then x86 would be simply unusable for mobile devices. It's that
easy. And we really do _NOT_ care about the existing laptop hardware
which does not provide that because it's a lost case. Not only due to
the missing (or just disabled) wakeup sources, also due to the fact
that you cannot do sensible power management by completely disabling
clock and/or power of unused devices in the chipset. There is a damn
good reason why the mobile space is _NOT_ x86 based at the moment.

Thanks,

tglx


\
 
 \ /
  Last update: 2010-05-31 22:53    [W:1.930 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site