Messages in this thread | | | Date | Wed, 5 May 2010 11:35:56 -0400 (EDT) | From | Alan Stern <> | Subject | Re: [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
| |