On Wed, 5 May 2010, Mark Brown wrote: > > 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. Then the underlying problem should be solved -- hopefully in a nice, system-independent way. But I'm still trying to understand exactly what that underlying problem _is_. That means understanding when the codec needs to be shut down and when it doesn't, and knowing how much of this information is available to the driver. > 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. One the face of it, a runtime-PM solution would dictate that the codec's driver ought to turn off the codec whenever the driver thinks it isn't being used. Ergo, if the driver didn't know when a call was in progress, it would use runtime PM to turn off the codec during a call. For this reason I don't see how using runtime PM instead of suspend blockers would solve anything. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
