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

["Arve Hjønnevåg" <arve@android.com>]

2010/5/7 Mark Brown <broonie@opensource.wolfsonmicro.com>:
> On Fri, May 07, 2010 at 03:57:37AM -0700, Arve Hjønnevåg wrote:
>> 2010/5/7 Mark Brown <broonie@opensource.wolfsonmicro.com>:
>
>> > As discussed elsewhere in the thread a suspend blocker is not desirable
>> > here - the AP is not doing anything useful on a voice call so blocking
>> > the suspend will just waste power unless runtime PM is good enough to
>> > mean opportunistic suspend isn't adding anything anyway.  It will avoid
>> > the immediate issue with loosing audio but it's not really what we want
>> > to happen.
>
>> I was talking about audio from the AP. Why would you ever turn off
>> another core's audio path on suspend?
>
> This goes back to the thing about a full system suspend being a
> sledgehammer which doesn't give enough information about what's going
> on when it's used like this.  As discussed we need a way to know that
> the connections involved are able to stay live during suspend (on a
> large proportion of systems suspend is going to mean that the relevant
> bits of the board will loose power so need to be shut down) and that

Are you trying to use the same driver on systems that can support
audio while suspend and on systems where this is impossible? If audio
cannot work while suspended, supporting opportunistic suspend is easy.
You block suspend while audio is active.

If the hardware does support some audio paths while suspended, I'll
ask again, is there a reason to turn them off on suspend?

> that the intention of the user is that they should do so (this isn't
> clear in the general system, especially not if the suspend is initiated
> manually).
>
> With a runtime PM approach this is trivial - we just turn off anything
> that isn't in use at the current time.  I'll need to extend ASoC to add
> information about what to do on suspend to the existing power data.
>
OK, but is this at all related to opportunistic suspend?

-- 
Arve Hjønnevåg