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