Re: [PATCH 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Wednesday 05 May 2010, Alan Stern wrote:
> 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.

We'd need a separate control, I think.  The problem is, though, that the
Android user space, for example, doesn't use the sysfs attributes of devices,
so this control wouldn't be particularly useful for it.

> 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?

I guess you end up telling the user that the call ended, so the system wakes up.
That's only a guess, though.

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/