Re: Attempted summary of suspend-blockers LKML thread

From: david
Date: Fri Aug 06 2010 - 21:02:22 EST

On Sat, 7 Aug 2010, Mark Brown wrote:

On Fri, Aug 06, 2010 at 04:35:59PM -0700, david@xxxxxxx 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

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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at