Re: [RFC Disable suspend on a specific device] This is a little change in linux power scheme

[Mark Brown <broonie@sirena.org.uk>]

On Tue, Apr 07, 2009 at 10:06:11AM +0200, Pavel Machek wrote:

> > the WM8753.  Audio from a bluetooth headset is decoded by and sent digitially 
> > to the WM8753 which does the digital to analogue conversion and 
> > routes it out via the appropriate outputs.
> > Analogue problem has the ti-caplyso when the audio is routed for a phone call.

> I still believe it should be done in the driver... at least
> today. Perhaps driver should just keep i2s/bluetooth powered up when
> it is in use.

The driver needs some way to figure out what it's supposed to do - it's
not immediately obvious without some policy information if suspend means
to suspend everything or if things that can keep working should do so.
The natural assumption for most systems would be that suspend means
suspend everything so that's what ASoC (the embedded audio subsystem
within ALSA) is doing.

Note also that there are multiple drivers involved in this decision.
The audio subsystem is separate from the bluetooth subsystem (which is
mostly managed from user space rather than by a driver) and the audio
subsystem is itself decomposed with three separate drivers in play,
though there is also an entry point for the subsystem which orchestrates
the audio side.  Keeping the audio live if the bluetooth suspends isn't
too useful.

> Perhaps we need new state 'sleep but keep working' for cases like
> that; echo mem > state should force machine to drop calls etc. There
> should be another value where stuff that is in use keeps being powered
> up; I also suspect that that's what android wants to use. 

That kind of devolves towards always driving to the lowest power
consumption (which we want to do anyway).  I suspect setting it system
wide would end up being too coarse grained.