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? thanks, greg k-h
