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

Eugeny S. Mints
2006-09-11T09:47:41Z

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