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

[Mark Gross <mgross@linux.intel.com>]

On Fri, Aug 18, 2006 at 11:10:02PM -0700, David Singleton wrote:
> On 8/14/06, Greg KH <greg@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@lists.osdl.org
> >https://lists.osdl.org/mailman/listinfo/linux-pm
> >


> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/linux-pm