On Mon, 2006-08-14 at 18:00 -0700, ext Greg KH wrote: > On Mon, Aug 14, 2006 at 07:48:01PM -0400, Dave Jones wrote: > > > > This adds a whole bunch of new code, and doesn't seem to make any > > existing code any simpler (to me at least). From a cpufreq point of view, > > what does adding this buy us? What problem do we have today that is > > being solved by all this? > > > > Every explanation of powerop I've seen so far dives into microdetails, > > whilst the 10,000ft view has always passed me by other than "this is > > what we've had in the embedded world". > > > > The diagram at http://lists.osdl.org/pipermail/linux-pm/2006-August/003196.html > > also confuses me. I was under the impression that powerop was adding additional > > userspace interfaces. If we're not changing how things from a userspace > > point of view, we're churning a lot of kernel code,.. why? > > > > Clue me in here, I'm feeling thick. > > You're not alone, I really don't get it either. > > But I guess we'll just wait for the next round of unified patches and > then go from there. Here is my shot at providing a 10,000ft view: a. For embedded platforms, cpufreq just does not cut it when specifying an operating point for the device. These platforms use tuples such as <voltage, pll_freq, core1_freq, core2_freq, interconnect_freq> to signify an 'operating point'. Note that core1 and core2 can be totally different processors e.g. ARM and DSP. x86 platforms hide this complexity behind ACPI. b. The clocking and voltage dependency tree in embedded devices can be summarised in the clock framework ( find ./arch -name clock* ) and soon-to-be-available voltage framework. These is again done to large extent by ACPI on x86. c. PowerOP provides an interface, that most embedded developers agree, is a good starting point to encapsulate platform information in a consistent way without having to resort to subarch-specific kludges. d. In the end, all this is leading to an interface for a user-space policy manager that will control _system_ power state based on constraints imposed by HW peripherals or on policies implemented by device manufacturer/distro maintainer. In conclusion, PowerOP only allows embedded platforms to join the PM fun without affecting cpufreq-supported platforms adversely. Or that is the original idea. If that rule is being violated, please feel free to point that out. The way forward as I see is: 1. PowerOP integration into mainline [patch 1/3] - PM Core drivers (OMAP, x86) [patch 2/3] - cpufreq drivers modified to use PowerOP (OMAP, x86) [patch 3/3] At this point, PowerOP is an optional component in mainline tree. Cpufreq drivers can _choose_ to use it or not. But now embedded platforms can do the PM dance in a consistent way. 2. Support for more architectures - PPC, x86_64, XScale, MIPS? Platform expertise needed here. 3. Move clock/voltage framework from arch/arm to kernel/clock and kernel/voltage. This would allow more embedded platforms and potentially future PC platforms to utilise the framework for 'automated' clock/voltage dependency management. 4. Userspace policy managers are created to provide basic control of system operating points. Embedded system integrators might want to extend these policy managers to fully utilise the 'knobs' available on their platforms. 5. <Crystal Ball Gazing/Wishful Thinking> - Clock/Voltage FW <--> ACPI logical mappings allows us to use global state names in /sys/power/state for system power state transitions. - Drivers on PC platforms are fixed to use/unuse resources dynamically to allow asynchronous peripheral power state transitions. Embedded platforms use clock framework for this. - PowerOP can address needs of all platforms, allowing removal of cpufreq. </CBG/WT> Regards, Amit -- Amit Kucheria <amit.kucheria at nokia.com> Nokia
