Hi! > > The other alternative as suggested earlier this week would be archictures > > getting to 'opt out' of powerop for their cpufreq drivers where it doesn't > > necessarily bring anything but the layer of indirection. > > > > I'm about to disappear for two weeks for a much needed vacation, but > > I'll be interested to see other folks comments/opinions on this > > when I get back. > > This week I got some really good feedback and suggestions > from Mark Gross on the kernel interface and usability and > I have two new additions for this patch set. So I spend the week > working on a well thought out kernel interface. > > 1) I believe I now have the right kernel interface for a common > power management infrastructure. > > The new kernel interface still uses /sys/power/state to both > show the current operating point and set a desired operating > point, by name. There is a new /sys/power/operating_points directory > that shows all the operating points the system supports. An > exampled from my centrino laptop shows: > > /sys/power/operating_points/high > /sys/power/operating_points/highest > /sys/power/operating_points/low > /sys/power/operating_points/lowest > /sys/power/operating_points/medium > /sys/power/operating_points/mem > /sys/power/operating_points/standby What makes you think that mixing operating and sleep states is good idea? And '600MHz' makes lot more sense than 'lowest' on centrino. > /sys/power/operating_points/high/frequency > /sys/power/operating_points/high/voltage > /sys/power/operating_points/high/latency What is voltage for 'mem'? > I've finally had a bit of time to get the sysfs one file - one > value system in place for OpPoint. > > 2) The really good news is there is a now a power manager for > OpPoint now, > both in rpm and src rpm form. And since the new power manager runs off > the new kernel interface and actually does what the cpuspeed daemon does > I think the kernel interface is sound. > > I took the cpuspeed power manager daemon, version 1.2.1, and modified > it Friday to use the oppoint interface. It supports all the > options the cpuspeed daemon does, (and can actually still be compiled to > be the original cpuspeed daemon) it just uses the interface > described above instead of the cpufreq interfaces. Congratulations, you now have inferior version of cpufreq ondemand governor. Pavel -- Thanks for all the (sleeping) penguins.
