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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
