lkml.org 
[lkml]   [2010]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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



    \
     
     \ /
      Last update: 2010-05-05 21:23    [W:4.083 / U:0.160 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site