Hi, Exporting the clock tree state is help us to monitor clocks state and to find the guilty clocks. But could it be also possible to have a write access to the clock tree ? During power consumption optimization step, we need to identify clock/regulator which should be disable but we also want to know what will be the gain. Instead of waiting for the new code with the right clock management, we generally want to directly disable it and look at the 1st result. It will be also useful when we are looking for the best clock tree configuration without developing/modifying a lot of source code.
For sure, such kind of feature is quite dangerous and must be enable carefully but it would help for optimizing power consumption. Vincent On 13 October 2010 12:40, Yong Shen <yong.s...@linaro.org> wrote: > Thanks for your guys' brainstorm. I will take all the thoughts into account > while implementing this. > > On Wed, Oct 13, 2010 at 2:49 PM, Amit Kucheria <amit.kuche...@linaro.org> > wrote: >> >> On 10 Oct 12, Arnd Bergmann wrote: >> > On Tuesday 12 October 2010, Amit Kucheria wrote: >> > > 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. >> > >> > I like the idea, too. >> > >> > One question I immediately had was whether it should be integrated into >> > sysfs or remain standalone in debugfs. >> > >> > In general, no core functionality should require debugfs, so if we find >> > it important enough to write user level tools on top of this, it should >> > probably become a stable interface either in sysfs or its own "clkfs" >> > file system if necessary. >> >> That is something I've been wondering about too. At the moment, tools like >> powerdebug have to periodically re-read the entire clock tree to show >> updates. AFAIK, sysfs and debugfs don't support inotify/poll/select >> mechanisms to >> notify changes. >> >> It would be nice to have notification, but I don't know how hard that >> would >> be for a virtual filesystem. >> >> > The main disadvantage of sysfs is probably memory consumption, which >> > will >> > have to be evaluated carefully: on systems with little RAM but many >> > clocks >> > this might amount to a few percent of the system memory just to manage >> > the inodes. >> > >> > The main advantage of sysfs is that we can interface it with the device >> > tree, >> > e.g. have a "clk" symlink in each device pointing to the entry in >> > the clock tree, and possibly vice versa. >> >> Agreed. >> >> /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
