On Tuesday 04 May 2010, Mark Brown wrote:
quoted text > On Tue, May 04, 2010 at 11:06:39AM -0700, Kevin Hilman wrote:
>
> > With opportunistic suspend, all of this flexibility is gone, and the
> > device/subsystem is told to go into the lowest power, highest latency
> > state, period.
>
> Well, half the problem I have is that unfortunately it's not a case of
> doing that period. The prime example I'm familiar with is that for
> understandable reasons users become irate when you power down the audio
> CODEC while they're in the middle of a call so if opportunistic PM is in
> use then the audio subsystem needs some additional help interpreting a
> suspend request so that it can figure out how to handle it. Similar
> issues apply to PMICs, though less pressingly for various reasons.
>
> Just to be clear, I do understand and mostly agree with the idea that
> opportunistic suspend presents a reasonable workaround for our current
> inability to deliver good power savings with runtime PM methods on many
> important platforms but I do think that if we're going to make this
> standard Linux PM functionality then we need to be clearer about how
> everything is intended to hang together.
At the moment the rule of thumb is: if you don't need the opportunistic
suspend, don't use it. It is not going to be enabled by default on anything
other than Android right now.
However, since Android is a legitimate user of the Linux kernel, I see no
reason to reject this feature right away. There are many kernel features
that aren't used by all platforms.
Rafael
--
unsubscribe notice To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/
Messages in current thread:
Re: [PATCH 0/8] Suspend block api (version 6) , Rafael J. Wysocki , (Tue May 4, 1:37 pm)