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, Matthew Garrett wrote:

> On Wed, May 05, 2010 at 03:20:40PM -0400, Alan Stern wrote:
>
> > 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.
>
> Well, part of the problem is that right now most of our beliefs about
> imposed constraints tend to be based on what userspace is doing - "Don't
> power down the audio codec when userspace has it open", for instance.
> But that goes away with opportunistic suspend. In most cases you don't
> want the audio codec to stay awake just because userspace was using it
> to make bouncing cow noises, especially if you've just frozen userspace.
> So the problem becomes more complicated than it would otherwise be.

It sounds like the problem can be stated simply enough: At the moment,
nobody knows when the codec should be powered down! Userspace might
have some idea, but even if its ideas are right it has no way of
communicating them to the kernel.

The power/control sysfs attribute was intended for just that purpose,
although it was aimed at runtime PM rather than system PM.
Nevertheless, it or something like it could be used. Of course, there
would still remain the issue of userspace telling the kernel not to
power down the codec while making bouncing cow noises -- but at this
point it's not really a kernel problem any more.

Alan Stern

P.S.: What happens if a suspend occurs while a call is in progress, so
the codec is left powered up, and then the call ends? Does the system
wake up at that point? Or does it stay suspended with the codec still
powered, even though it's not needed any more?



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