On Wed, May 05, 2010 at 02:36:10PM -0400, Alan Stern wrote: > Clearly if there's a call in progress you don't want to shut the codec > down. Are there any other circumstances? Would they vary according to > whether the suspend was forced or opportunistic? Aside from things where the CODEC is acting as a wake source (for stuff like jack detect) which are obviously already handled it's basically just when you've got an external audio source flowing through the device which is going to continue to function during suspend. Things like FM radios, for example. I'm not aware of non-audio examples that are use case specific and don't just involve utterly ignoring AP suspends. > In short, I'm trying to get at how much information drivers _really_ > need to have about the reason for a system suspend. It's not exactly the *reason* that makes the difference, it's more that this aggressive use of suspend makes much more apparent a problem which might exist anyway for this sort of hardware. When we get runtime PM delviering similar power levels we'll sidestep the problem since we won't need to do a system wide suspend. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
