Re: Attempted summary of suspend-blockers LKML thread
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
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/