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
