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

[Brian Swetland <swetland@google.com>]

On Wed, May 5, 2010 at 4:06 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, May 05, 2010 at 02:22:30AM +0200, Rafael J. Wysocki wrote:
>> On Wednesday 05 May 2010, Mark Brown wrote:
>
>> > On a mobile phone when the system is in a voice call the data flow for
>> > the call is entirely handled outside the CPU (normally referred to as
>> > Applications Processor or AP here) by the baseband and audio CODEC,
>
>> In that case someone (either a driver or, most likely, user space) will need to
>> keep a suspend blocker active.
>
> That is not actually what Android systems are doing, and if it is what's
> supposed to happen then I'd really expect to see a patch to ASoC as part
> of this series which shows how this is supposed to be integrated - it's
> the sort of thing I'd expect to see some kernel space management for.
>
> Honestly I don't think that's a very good solution for actual systems,
> though.  A part of the reasoning behind designing systems in this way is
> allowing the AP to go into the lowest possible power state while on a
> voice call so it doesn't seem at all unreasonable for the system
> integrator to expect that the AP will be driven into the standard low
> power state the system uses for it during a call and in a system using
> opportunistic suspend that's suspend mode.

Yup.  And that's exactly what happens on the platforms we've shipped
on so far -- the apps side of the world fully suspends while in a
voice call.  Some events (prox sensor, buttons, modem sending a state
notification) will wake it up, of course.

I haven't spent much time looking at alsa/asoc yet, but it's on my
list for 2010 -- I'm hoping to migrate the very simple audio drivers I
wrote for the msm platform originally to actually be alsa drivers as
part of the general "try to use existing interfaces if they fit" plan
we've been working toward.

The suspend_block system gets us what we need today (well what we
needed three years ago too!) to ship and hit reasonable power targets
on a number of platforms.  There's been a lot of various handwaving
about "android kernel forks" and what have you, but here we are again,
trying to work out perhaps the only "new subsystem" type change that
our driver code depends on (almost all other contentious stuff is self
contained and you can take or leave it).

Our hope here is to get something out there in the near term so that
the various drivers we maintain would "just work" in mainline (your
choice of if you use suspend_block or not -- it's designed to be an
option) and we can move forward.  If in the future runtime power
management or other systems completely obsolete suspend_blockers,
awesome, we remove 'em.

Brian