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
