On Mon, 16 Feb 2009 16:36:43 -0600 "Woodruff, Richard" <r-woodruff2@xxxxxx> wrote: > > > From: Arjan van de Ven [mailto:arjan@xxxxxxxxxxxxx] > > Sent: Monday, February 16, 2009 3:52 PM > > On Mon, 16 Feb 2009 15:32:06 -0600 > > "Woodruff, Richard" <r-woodruff2@xxxxxx> wrote: > > > > > > - It provides a way to handle overdrive/turbo operating points > > > out of band from the generically tuned cpufreq governors like > > > ondemand. The way we characterize overdrive is stricter then > > > what Intel has talked about for x86. > > > > if you have an improved-for-your-systems governor then I'm sure > > that is very welcome in the kernel. > > No, the generic governors were not substantially improved. Not every > customer is using cpufreq for DVFS. As such we went underneath it. If > we had more community presence at the start time we might have also > tried that. > > > I think just about all of us agree that the final decision needs to > > be in the driver (possibly followed by something that gets various > > device requests and combines it into hw settings); we're just > > talking about what inputs feed into that decision ;) > > > > And for different types of devices that's guaranteed to be > > different... and sometimes we'll be hampered by existing > > interfaces, so we might end up with hacky stuff. > > Is there some kind of roadmap which can be plotted which goes from > course to more granular control? > > Phase 1 (all or nothing): like wakelocks (minus back light): > system-auto-suspend-on, system-auto-suspend-off. The drivers can > still veto as they do today. > > Phase 2: Subsystem generic tunable, on say latency + bandwidth. Start > with CPU then move to classes like USB. I think your phases are the wrong way around. Phase 2 is already in progress and many of the "good" drivers and subsystems already do them. Whole system suspend is a much more drastic thing; I don't see that happen generically in 2009 to be honest (not to mention how fragile linux suspend is). In addition, in hardware there does seem to be the trend where idle and suspend are converging (just look at the OLPC)... with chipsets powering down all unused pieces, and cpus in idle taking basically no power, there no longer is much of a difference in reality between suspend and good-idle... -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
