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:

    > Now, the solution here if we're going to use opportunistic suspend like
    > this is to provide some method for the audio subsystem to figure out
    > that the system doesn't actually want it to suspend when it gets told do
    > do so. Like I say ideally we'd provide some standard interface in the
    > PM subsystem for userspace to communicate this to subsystems and drivers
    > so that we've got a joined up story when people run into issues in cases
    > like this, though obviously if this goes in then we'll have to put in
    > something subsystem or driver specific for affected areas. I know what
    > I'd implement generically for audio, but I've held back since the option
    > is fairly messy when not used in conjunction with a deliberate choice to
    > use opportunistic suspend and I was expecting a standard mechanism to
    > slot into to provide control for userspace.
    >
    > In other words, the issue is that we run into situations where we need
    > an element of suspend control to go along with the opportunistic suspend
    > in order to allow some elements to be kept running - since suspend
    > blocking is taken suspend suppression seems like a reasonable term.

    Android must already include some solution to this problem. Why not
    use that solution more generally?

    Alan Stern



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