On Fri, Aug 18, 2006 at 11:10:02PM -0700, David Singleton wrote: > On 8/14/06, Greg KH <greg at kroah.com> wrote: > >On Mon, Aug 14, 2006 at 07:48:01PM -0400, Dave Jones wrote: > >> > >> This adds a whole bunch of new code, and doesn't seem to make any > >> existing code any simpler (to me at least). From a cpufreq point of > >view, > >> what does adding this buy us? What problem do we have today that is > >> being solved by all this? > > Greg and Dave, > > there are two competing patch sets for a new power > management > framework. The patch set I sent out simplifies power management, > from both the cpufreq perspective and the embedded world's view of > power management. Why can't we have one evolve a single powerOP framework? Both of these patches are derived from The MV/Todd Poynor's patches. It seems "funny" to not coordinate these two patch sets. > > I've renamed my patch oppoint so as not confuse it > with the powerop set from Matt Locke (which will probably make > it even more confusing). I've renamed it so it can be seen as an > alternative design approach, not just an alternative implementation > of the same ideas. I've also incorporated suggestions from > Pavel in cleaning up the original patches. > > If you'd be willing to take a look at, or try out, the > patches > in my patch set you should be able to see how oppoint could simplify > cpufreq code. The first patch is the oppoint-cpufreq.patch and > the second is the oppoint-x86-centrino.patch. How would the ACPI cpufreq_driver be integrated with this design? > > 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. How will the users of on-demand make use of this design? I don't think you can just dump the governor function of CPUFREQ for user defined performance control. > > 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. re-using the cpufreq notification infrastructure makes sense. > 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 Only for user mode governors, I believe kernel mode governors still have role in Linux. --mgross > 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. > > The entire patch set can be found at: > > http://source.mvista.com/~dsingleton/2.6.18-rc4/ > > The patch set consists of: > > oppoint-core.patch > oppoint-cpufreq.patch > oppoint-x86-centrino.patch > oppoint-arm-pxa27x.patch > > I'll attach oppoint-cpufreq.patch to this email and > send out oppoint-x86-centrino.patch next. > > > David > > > > >> > >> Every explanation of powerop I've seen so far dives into microdetails, > >> whilst the 10,000ft view has always passed me by other than "this is > >> what we've had in the embedded world". > >> > >> The diagram at > >http://lists.osdl.org/pipermail/linux-pm/2006-August/003196.html > >> also confuses me. I was under the impression that powerop was adding > >additional > >> userspace interfaces. If we're not changing how things from a userspace > >> point of view, we're churning a lot of kernel code,.. why? > >> > >> Clue me in here, I'm feeling thick. > > > >You're not alone, I really don't get it either. > > > >But I guess we'll just wait for the next round of unified patches and > >then go from there. > > > >thanks, > > > >greg k-h > >_______________________________________________ > >linux-pm mailing list > >linux-pm at lists.osdl.org > >https://lists.osdl.org/mailman/listinfo/linux-pm > > > _______________________________________________ > linux-pm mailing list > linux-pm at lists.osdl.org > https://lists.osdl.org/mailman/listinfo/linux-pm
