On Wed, May 05, 2010 at 03:13:52PM -0400, Alan Stern wrote: > Should the audio driver be smart enough to know that the codec needs to > remain powered up during every opportunistic suspend? > Or only during opportunistic suspends while a call is in progress? I think for simplicity and maximum flexibility we should just ignore the reason for suspend here, if I'm adding support for this in the drivers the suspend reason is not going to be terribly useful and it makes the feature more widely useful should people come up with other applications. Note that we already have advanced runtime PM for embedded audio which will drive modern CODECs into full off state when the device is idle anyway, independently of any suspend or runtime PM that the system does. Older CODECs need their bias levels maintaining but we can ignore the difference there from this point of view. > Does it know when a call is in progress? Not at present. This is relatively straightforward to add within ASoC, especially for analogue links, if not completely trivial. Digital basebands are a bit more fun but not insurmountable (and need cleaning up anyway, there's some ongoing work which should hit soon). We currently drive everything into off state when we're told to suspend since it's the right thing to do for most non-phone devices. We'll still need to drive some of the system into an off state (eg, some of the drivers in the CPU) even when this is handled. > Does Android use forced suspends? Pass, but it's not been an issue users have raised with me - but then we can't tell why the suspend happens and need to handle opportunistic suspend anyway. > If it does, are they supposed to shut down the codec? I suspect it's a non-issue; if we're not actually using audio then ASoC will drive a modern CODEC into power off anyway as part of its runtime PM. However, I believe some non-Android phone stacks are doing something along that line. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
