On Wed, 5 May 2010, Matthew Garrett wrote: > > Clearly if there's a call in progress you don't want to shut the codec > > down. Are there any other circumstances? Would they vary according to > > whether the suspend was forced or opportunistic? > > Yeah, ok. We probably do need to figure this out. > > (Cc:ing Rebecca to see how this got handled on Droid) > > The current state of affairs is that a system suspend request is > expected to put the device in as low a power state as possible given the > required wakeup events. Runtime power management is expected to put the > device in as low a power state as possible given its usage constraints. > If opportunistic suspend does the former then it'll tear down devices > that may be in use, but we don't have any real way to indicate usage > constraints other than the phone app taking a wakelock - and that means > leaving userspace running during calls, which seems excessive. > > Mark's right in that the only case I can think of that's really relevant > right now is the audio hardware, so the inelegant solution is that this > is something that could be provided at the audio level. Is this > something we want a generic solution for? If so, what should it look > like? Should the audio driver be smart enough to know that the codec needs to remain powered up during every opportunistic suspend? Or only during opportunistic suspends while a call is in progress? Does it know when a call is in progress? Does Android use forced suspends? If it does, are they supposed to shut down the codec? Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
