Re: [PATCH 0/8] Suspend block api (version 6)

[Brian Swetland <swetland@google.com>]

On Wed, May 5, 2010 at 12:13 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Wed, 5 May 2010, Matthew Garrett wrote:
>
>> > Clearly if there's a call in progress you don't want to shut the codec
>> > down.  Are there any other circumstances?  Would they vary according to
>> > whether the suspend was forced or opportunistic?
>>
>> Yeah, ok. We probably do need to figure this out.
>>
>> (Cc:ing Rebecca to see how this got handled on Droid)
>>
>> The current state of affairs is that a system suspend request is
>> expected to put the device in as low a power state as possible given the
>> required wakeup events. Runtime power management is expected to put the
>> device in as low a power state as possible given its usage constraints.
>> If opportunistic suspend does the former then it'll tear down devices
>> that may be in use, but we don't have any real way to indicate usage
>> constraints other than the phone app taking a wakelock - and that means
>> leaving userspace running during calls, which seems excessive.
>>
>> Mark's right in that the only case I can think of that's really relevant
>> right now is the audio hardware, so the inelegant solution is that this
>> is something that could be provided at the audio level. Is this
>> something we want a generic solution for? If so, what should it look
>> like?
>
> Should the audio driver be smart enough to know that the codec needs to
> remain powered up during every opportunistic suspend?
>
> Or only during opportunistic suspends while a call is in progress?
>
> Does it know when a call is in progress?

>From my point of view, the codec should be powered up while audio is
playing and powered down when it's not -- that's the approach I've
taken on MSM, regardless of suspend state.  I don't view suspend as
something that stops audio playback in progress.  Sort of similar to
how the modem doesn't power off down when the system is in suspend,
etc.

In effect, we have followed a sort of runtime pm model of
clocking/powering peripherals at the lowest possible level at all
times, which is why I've never viewed suspend_block as somehow
competing with runtime pm -- we always want all drivers/peripherals in
the lowers power state.  Sometimes the lowest power state possible is
higher than "full suspend" (for example when we can't meet latency
requirements on audio on 7201A) and suspend_blockers cover that case.

Brian