On 8/21/06, Greg KH <greg at kroah.com> wrote:
> On Fri, Aug 18, 2006 at 11:10:02PM -0700, David Singleton wrote:
> > Oppoint could replace large pieces of the cpufreq code
> > in the kernel, most notably the policy and governor code, which I
> > believe belongs in user space in the power manager daemon.
> >
> > You'll notice that the oppoint-cpufreq.patch only touches
> > two files, cpufreq.c and cpufreq.h. It only creates two new
> > interfaces
> > to the cpufreq frequency scaling notifier lists to support driver pre
> > and post scaling routines, already supported in the kernel.
> >
> > The oppoint-x86-centrino.patch completes the replacement
> > of cpufreq code by introducing the transition routine to
> > change frequencies and creates operating points for the
> > centrino-speedstep processors already supported by Linux.
> >
> > (although I've recieved a note from Intel that the data I've copied
> > from the centrino-speedstep cpufreq tables is known to be inaccurate
> > and unsupported)
> >
> > This code could replace cpufreq code and simplify it quite a
> > bit in the process. The kernel drivers that support cpufreq
> > frequency
> > scaling would not have to be changed. Operating points for the rest
> > of the processors that support cpufreq would have to be created, but
> > as you can see it's quite a straight forward transformation from
> > a cpufreq table to a set of operating points for a processor.
>
> This only touches on the cpu frequency stuff. I am assuming that the
> current driver interface to the different power management states is
> acceptable to you?
Yes. The driver interface works perfectlly with the operating point design.
The power manager can simply set whatever operating point it wants the system
to be in and still have the flexibility to suspend individual devices through
the current driver interface. Drivers do not have be changed in any way
to operate correctly with the operating point model.
The cpufreq driver scaling code doesn't need to changed either. OpPoint
calls the same scaling routines throught the same notifier chain as
cpufreq does.
That's two of the big advantages to the OpPoint design,
the driver interace doesn't need to change and the existing driver frequency
scaling code doesn't need to change either.
Which makes sense since the operating point design is performing the same
functionality, just in a simpler manner.
I still have to write a power manager for this so all the
policy/class stuff
that's being discussed now can be plug-ins for the power manager. You'd
set you power management classes and policies up in the power manager,
wether its' performance, or energy efficiency, or thermal constraints,
or battery
constraints, and let it simply set operating states and handle
individual devices
as it sees fit.
That's really where all the policy/class code belongs, in the
power manager.
OpPoint just provides a simpler interface for the power manager. The operating
points are set by their name and the device control works just as it does today
through the sysfs interface.
David
>
> thanks,
>
> greg k-h
>
