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

Pavel Machek
2006-09-11T19:36:37Z

Hi!

> >>>>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

Kernel interface is not something to be experimented with.

> 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.

...and configurable kernel interfaces are very bad idea.

> >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

Okay, drop sysfs interface, and we may have something that can be
reviewed.

Actually that's good idea. Submit powerop without doing _any_ kernel
interface changes, so we can see that it makes sense...

> 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.

...bonus points if your submission actually deletes more code than it
adds.

> >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.

Your code should be good enough to survive some flaming. I do not
think it is, so yes, I think submitting it to lkml is good
idea. You'll have to do that at some point, anyway.

(And note lkml only flames you when you are doing something wrong.)

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html