Messages in this thread | | | Date | Wed, 5 May 2010 15:20:40 -0400 (EDT) | From | Alan Stern <> | Subject | Re: [PATCH 0/8] Suspend block api (version 6) |
| |
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
| |