Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Dominik Brodowski <linux@dominikbrodowski.net>]

Hi,

Just to set the record straight:

On Tue, Sep 12, 2006 at 02:05:26AM +0400, Eugeny S. Mints wrote:
> Cpuferq defines cpufreq_frequency_table structure in arch independent header 
> while it's arch dependent data structure.

cpufreq_frequency_table is an _optional_ library architectures _may_ use if
they consider it useful to them. It's useful for most of them, but it is not
required at the core level. For a reason.

> A lot of code is built around this 
> invalid basic brick and therefore is invalid: cpufreq tables, interface with cpu 
> freq drivers, etc.

cpufreq tables? what do you mean with that?

And the interface with cpufreq drivers does not rely on
cpufreq_frequency_table. That's one of the fun things in cpufreq. You don't
need to define a pre-defined table for the >10^5 states at least one cpufreq
driver offers.

> Notion of transition latency as it defined by cpufreq is 
> wrong because it's not a function of cpu type but function of current and next 
> operating point.

That may be, but it may serve as the "maximum latency" at the moment; if
needed, it could be expanded, e.g. using or on top of the interfaces
described in http://lwn.net/Articles/197299/ .

> no runtime control on operating points set. it's always the 
> same set of operating points for all system cpus in smp case and no way to 
> define different sets or track any dependencies in case say multi core cpus. 

You can define different min, current, and max frequencies (for this is all
the cpufreq core cares about) for multiple cores. How the freq_table
interactions work then, I cannot say without checking the source -- but as
it is only an _optional_ library an arch can use, that doesn't count.

> insufficient kernel<->user space interface to handle embedded requirements and 
> no way to extend it within current design.

Nobody tried to do so yet, to my knowledge.

> PowerOP/cufreq integration patch set contains very details explanation of the 
> cpufreq design issues and POwerOP solutions. Comment there is you feel it's wrong.

I'll gladly do so soon, and I'll also comment further on the PowerOP patches -- but
not today, sorry.


Thanks,
	Dominik