Re: So, what's the status on the recent patches here?

[Pavel Machek <pavel@ucw.cz>]

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.