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

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Fri, May 07, 2010 at 05:37:21AM -0700, Brian Swetland wrote:
> On Fri, May 7, 2010 at 5:25 AM, Mark Brown

> > It's unfortunate that I only noticed that this was actually wakelocks
> > very late in the day but I think I can get an implementation which
> > handles paths that ignore suspends done quickly.

> Do you mean an implementation of embedded linux audio or an
> implementation of suspend blockers "which handles paths that ignore
> suspends"?  I assume you mean the former, but maybe I misunderstand.

I mean that I will extend the embedded audio subsystem that the kernel
already has (ASoC, in sound/soc) to support ignoring suspends for some
audio paths so that they can be kept up during suspend.  This will be
primarily intended for use with opportunistic suspend but not specific
to it.

I have no intention of touching suspend blockers, except in that some of
the drivers I'm responsible for should probably use suspend blockers for
similar reasons to the other users you're merging but that's less urgent.

> We've done a lot of work around multicore SoCs where the baseband
> generally owns a lot of the audio routing and so on,

Multicore isn't really the term here - obviously on something like the
OMAP4 or the current nVidia devices you've got a multicore AP but may or
may not have an integrated baseband.  The distinction is down to how
much visibility the AP has of the audio hardware, which is in general
orthogonal to how the silicon is split and packaged.

>                                                      but we do as
> general policy not disable audio, codecs, and amps while playback or
> record is underway.

Yeah, I know.  I have been keeping an eye on the Android stuff, though
none of the audio side has been mainlined yet.

>                      I suppose for environments more like a pc laptop
> where the expectation is the world stops when you close the lid a
> different policy would be preferable.

Yes, quite.  It all depends on what the intention of the user is when
they do a suspend.  Clearly if the suspend was initiated automatically
because the system is apparently idle the intention is different to if
it was initiated because the user performed some explicit action.

> We typically fire up codecs and amps when playback starts (if they
> were off), and usually set a timer for a couple seconds after playback
> stops to spin them down (since you tend to have to delay while they're
> powering up to avoid pops, etc, and if the system just played a short
> sound there's a reasonable chance it'll follow that with another).

This is exactly what ASoC does - the two biggest wins it offers are that
it allows reuse of the code specific to a given piece of silicon on all
boards using that silicon and that it provides automatic runtime power
management in the core by keeping track of which audio paths are live.

There is the slight wrinkle that you don't really want to *fully* power
down devices that don't have ground referenced outputs since they take
a relatively long time to bring their reference level up without audible
artifacts in the output.