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 <> 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 <> 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.