2010/5/7 Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>: > On Wed, May 05, 2010 at 09:25:18PM -0700, Arve Hjønnevåg wrote: >> On Wed, May 5, 2010 at 4:40 PM, Mark Brown > >> > This really does depend heavily on system design and the intended >> > function of the suspend on the part of the initiator. In many systems >> > suspend will remove sufficient power to stop audio running even if it >> > were desired, and there's the idea with existing manually initiated >> > suspends that the system should stop what it's doing and go into a low >> > power, low responsiveness state. Some systems will initiate a suspend >> > with active audio paths (especially those to or from the AP) which they >> > expect to be stopped. > >> You can support both in the same driver in some cases (without a >> switch). If the hardware cannot wake the system when it needs more >> audio buffers, then the driver needs to block suspend while audio is >> playing. Since suspend blockers only block opportunistic suspend, the >> driver can also implement suspend to stop audio playback and it will >> only be called for forced suspend. > > 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? -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
