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

["Eugeny S. Mints" <eugeny.mints@gmail.com>]

Pavel Machek wrote:
> Hi!
> 
> On Mon 2006-09-11 11:57:28, Eugeny S. Mints wrote:
>> [snip]
>>>> Are you arguing that the cpufreq interface be morphed to support power
>>>> op applications?
>>> No. I'm arguing that
>>>
>>> * cpufreq interface should be used for changing cpu frequency
>> the patch set i sent out has cpufreq used for changing cpu frequency,
>> hasn't it?
> 
> I was talking about kernel<->user interface.
me too. PowerOP is inkernel interface but which _allows_ to build various
different kernel<->user interfaces on top of it. This PowerOP _advantage_ allows 
community to experiment with various kernel<->user interfaces on top and 
eventually end up with the best solution. The solution can be either one 
universal, agreed by community kernel<-> user interface on top or I can imaging 
the approach when kernel<-> user interfaces on top are configurable feature and 
system designer choses kernel<->user interface which fits best the systems 
he/she builds.
> 
> You did echo low > something to change CPU frequency, IIRC.
My patch set presents two different interfaces built on top of PowerOP - cpufreq 
and sysfs interfaces. So _no_, PowerOP is not all about 'echo low > something'. 
Such kernel<-> user interface is  an _option_. PowerOP supports full _legacy_ 
cpufreq interface as another option - please check out PowerOP/cpufreq 
integration patch set. The goal is either to end up with one kernel<->user 
interface which addresses both pc world and embedded world requirements to 
user<->kernel interface _or_ - as an alternative I'd prefer - have these 
kernel<->user interfaces configurable: if you build laptop  system - chose 
cpufreq interface on top of PowerOP; if you build embedded - chose sysfs 
interface. But with the approach when everything is built on top PowerOP[PM 
Core, Clock framework] you just eliminate all unnecessary duplication if PM 
functionality in PM  stack.

Just in case you are confused by the fact I didn;t send out PowerOP/cpufreq 
integration patch along with the last PowerOP Core take: PowereOP Core patch I 
sent out in the last take is a standalone functional piece. PowerOP/cpufreq 
integration patch is just a further extension and applies to the most recent 
POwerOP Core without any changes so there was no reason to resend 
PowerOP/cpufreq integration.
> 
>> can we eventually start talking more close to the code rather than
>> speculating without it?
> 
> Lets get kernel<->user interface right, first. You'll need to create
> Documentation/ entries for your interfaces, eventually, so lets do
> that, first, and then talk about code.
Documentation/ piece is fine, I will add it. But I feel I put quite detailed 
comments along with the patches at least to explain interfaces.
> Oh and it would be nice to cc
> lkml on that document, too. New kernel<->user interface is not
> decision taken lightly.
PowerOP Core and PowerOP/cpufreq integration patch sets present two clear and 
configurable kernel<->user interfaces. I personally feel that interfaces 
configuration feature allows graceful interface discussion and possibility to 
get a decision smoothly instead of a flame on a list. If you argue against 
configuration feature please put comments on exactly configuration feature. 
Otherwise please explicitly list the requirements for kernel<->user interface 
you have which are not addressed by these two interfaces assuming you can chose 
either interface having PowerOP underneath.

Thanks,
	Eugeny
> 									Pavel