lkml.org 
[lkml]   [2010]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 0/8] Suspend block api (version 6)
    Date
    On Thursday 06 May 2010, Kevin Hilman wrote:
    > Alan Stern <stern@rowland.harvard.edu> writes:
    >
    > > 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.
    >
    > I guess what we're talking about here is a set of per-device
    > constraints that could be used by both [opportunistic|system] suspend
    > and runtime PM. For lack of a better term, per-device PM QoS (as
    > compared to the current system-wide PM QoS.)
    >
    > For example, if userspace (or some other device) has communicated that
    > it has a constraint on the audio HW, then both the suspend path and the
    > runtime PM path could check those constraints before making a decision
    > on how to act. Hopefully the phone app would set a constraint and the
    > cow-noise app would not. :)
    >
    > On OMAP, we keep track of per-device constraints (currently latency
    > and throughput) in order to make proper run-time PM decicions in the
    > kernel, but we are realizing that we need a way for userspace to
    > communicate these constraints as well, so that userspace can make
    > power vs. performance policy decisions instead of the kernel.
    >
    > Probably generalizing these into the LDM is the direction to go so
    > userspace can set constraints on a per-device (or per-class?) basis:
    >
    > /sys/devices/.../power/constraint/throughput
    > /sys/devices/.../power/constraint/wakeup_latency
    > /sys/devices/.../power/constraint/... ?

    That sounds reasonable although it may be a challenge to find a set of
    universal constraints common to all devices.

    Rafael


    \
     
     \ /
      Last update: 2010-05-06 01:19    [W:7.323 / U:0.852 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site