Hi, The goal of the patch is to provide an easy way to find the guilty clocks when we are optimizing the power consumption of a platform. I agree with you that it's not enough for a complete PM and it might be extended to other features (in addition to regulator framework). Such debug interface should used to test and find the optimized configuration that will be used by runtime PM framework as an example. Such optimization step takes a lot of time and a part of this time is generally used to export some debug interfaces and develop some tools.
Vincent On 17 October 2010 13:55, Amit Kucheria <amit.kuche...@linaro.org> wrote: > Hi Kevin, > > On Sat, Oct 16, 2010 at 2:55 AM, Kevin Hilman > <khil...@deeprootsystems.com> wrote: >> Amit Kucheria <amit.kuche...@linaro.org> writes: >> >>> Adding linaro-dev to cc. Kernel consolidation WG might have comments. >>> >>> On Tue, Oct 12, 2010 at 9:04 AM, Yong Shen <yong.s...@linaro.org> wrote: >>>> Hi Amit and Jeremy, >>>> >>>> This is not a patch review. But patch may better present my idea. >>>> Basically, >>>> I want to add some code in common clock code to export clock information, >>>> so >>>> every platform can benefit. This information is present in a tree-like >>>> pattern. >>>> Currently, each platform uses their own way to show clock info, which is >>>> hard to use a common user space tool to collect information. >>>> For this purpose, I need do the rest: >>>> 1. Add a clock name check in the clkdev_add. We don't accept two clocks >>>> with >>>> the same name to clkdev_add, do we? otherwise, it is impossible to create a >>>> tree-like structure under file system, cause no same names under a >>>> directory. >>>> 2. Recursive function creates the clock tree in debugfs, which referred >>>> omap's clock implementation. >>>> 3. Add interface needed to let mach related drivers to report their >>>> information. clk_get_rate is already there. Maybe we need clk_get_flags() >>>> and clk_get_usecount() and more. >>> >>> Agreed, this functionality is necessary for common clk infrastructure >>> to be useful. >>> >>> We've also incorporated this functionality into a tool called >>> powerdebug that'll show runtime state of the clock tree. This is very >>> useful for driver developers. >> >> IMO, I think this is going somewhat down the wrong path, at least in >> terms of power management controls. > > We're not approaching it solely from the angle of PM controls. This > work is targeted towards platform consolidation across various SoCs. > >> I know that most drivers assume that a clock is the primary PM "knob" >> for a given device, but there is *lots* more to device PM than clocks. > > Agreed wholeheartedly. Power domains, per-device runtime states, > system states are all critical to satisfy the classic low-power > usecases. To that end, we're working to consolidate the information > exported by the building blocks (clock framework, regulator framework, > cpuidle states, cpufreq states, etc.) and develop tools to provide > more insight on the runtime state of the system. At the moment, every > SoC vendor is reimplementing the wheel - we want to consolidate those > bits first. > >> For that reason, on OMAP, we are now moving all drivers to use the >> runtime PM framework, so for power management drivers do not have to >> know anything about their clocks, and as a result most drivers don't >> have to know about *any* clocks. They just use runtime PM 'get' and >> 'put' calls when they want the device to be active. > > We're tracking that work with a lot of interest. > >> That being said, I'm not against $SUBJECT patch, but I question it's >> usefulness in terms of PM. What's more valuable for PM is the statitics >> and knobs exported on a per-device level by the runtime PM core (and >> AFAICT, already included into tools like powertop.) > > Other platforms aren't yet using the per-device runtime PM framework. > But I am learning a lot from the conversion of OMAP drivers to use > these new features. I'm also tracking the work being documented at > http://www.omappedia.org/wiki/Power_Management_Domain_Wiki > > Regards, > Amit > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
