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.
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.
Arnd
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
