Re: [PATCH 0/8] Suspend block api (version 6)

[Alan Stern]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/