Hi! > >> 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. > > 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. > > 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. I was told (by intel folks) that you can't push governor code into userspace, because it is latency-critical on new cpus... so I do not think this is going to simplify cpufreq. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
