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

[Pavel Machek <pavel@ucw.cz>]

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