Believe me, it is very useful in both BSP development and SOC power management. In the company I am working for, people are keen to have this kind of info.
On Sat, Oct 16, 2010 at 7: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. > > 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. > > 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. > > 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.) > > Kevin >
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
