On Wed, May 5, 2010 at 4:03 PM, Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> wrote: > > 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/... ? The constraint stuff is definitely something I'd love to talk about in detail. It's a problem that I think is common to every SoC I've worked with. Having a general solution for this problem (of specifying and observing various constraints for clock, power, qos, etc) kernel-wide would seem like a big win. Might be worth kicking some design ideas around and getting a bunch of the interested parties together at some of the upcoming linux conference things this fall on the east coast? Brian _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
