Re: Attempted summary of suspend-blockers LKML thread

david
2010-08-07T01:00:34Z

On Sat, 7 Aug 2010, Mark Brown wrote:

> On Fri, Aug 06, 2010 at 04:35:59PM -0700, david@lang.hm wrote:
>> On Fri, 6 Aug 2010, Paul E. McKenney wrote:
>
>> So as I see it, we need to do one of two things.
>
>> 1. change the suspend definition to allow for some things to not be
>> suspended
>
> This is essentially what's already happening.
>
>> 2. change the sleep/low-power mode definition to have a more standardized
>> way of turning things off, and extend it to allow clocks to be turned off
>> as well (today we have things able to be turned off, drive spin-down for
>> example, but per comments in this thread it's all one-off methods)
>
> Currently things like clock trees are frequently managed orthogonaly to
> the system power state to at least some extent anyway - for example,
> perfectly normal wake events like button presses will often require
> clocks for things like debouncing.

I recognise that #1 is essentially what Android is already doing.

I'm asking the question, "Is this what Linux should be doing?

Personally, I think that suspend should be treated much more like a
low-power state and much less like hibernation than it currently is (I
believe that Linus has also voiced this opinion). And I think that the
situation with Android suspending while audio is playing between busts of
CPU activity is a perfect example.

for the moment, forget the problem of other apps that may be running, and
consider a system that's just running a media player.

the media player needs bursts of CPU to decode the media so that the
output device can access it (via DMA or something like that)

the media player needs bursts of I/O to read the encoded program source
from storage.

What we want to have happen in an ideal world is

when the storage isn't needed (between reads) the storage should shutdown
to as low a power state as possible.

when the CPU isn't needed (between decoding bursts) the CPU and as much of
the system as possible (potentially including some banks of RAM) should
shutdown to as low a power state as possible.

today there are two ways of this happening, via the idle approach (on
everything except Android), or via suspend (on Android)

Given that many platforms cannot go to into suspend while still playing
audio, the idle approach is not going to be able to be eliminated (and in
fact will be the most common approach to be used/deugged in terms of the
types of platforms), it seems to me that there may be a significant amount
of value in seeing if there is a way to change Android to use this
approach as well instead of having two different systems competing to do
the same job.

David Lang