Hello Hiroshi,
On Thu, 17 Apr 2008, Hiroshi DOYU wrote:
> debugfs can provide the infrastructure to trace the dependencies of
> clock tree hierarchy quite visibly. This patch enables to keep track
> of clock tree hierarchy and expose their attributes under each clock
> directry as below:
As a replacement for print_parents, which was read-only, it seems good to
me.
But it would be nice to be able to call into clock functions like
round_rate, set_rate, and set_parent via filesystem writes for debugging
purposes, and I don't think that debugfs supports this.
I have a patch here that I use for internal testing that builds the clock
tree in sysfs, and allows for round_rate/set_rate calls, along with
enable/disable testing. But sysfs may not be the right place. It doesn't
seem like there's any logical place to put it that would not involve major
upstream arm-wrestling. Maybe /sys/devices/platform?
There are also procfs and configfs, I suppose.
Obviously, I could continue to carry my debugging patch in my local tree
here. But you mention powerdomain links. I suspect that we will want to
have a standard place for all of these filesystem entities, particularly
since one could conceive of a completely userspace power management policy
that would control powerdomains and clockdomains via the filesystem. So
it probably makes sense to discuss this now.
A quick comment on the patch itself, inlined below.
> +static int clk_debugfs_register_one(struct clk *c)
> +{
> + int err;
> + struct dentry *d, *child;
> + struct clk *pa = c->parent;
> + char s[255];
> + char *p = s;
> +
> + p += sprintf(p, "%s", c->name);
> + if (c->id != 0)
> + sprintf(p, "%d", c->id);
perhaps separate the ID and the clock name with a colon, if the ID exists?
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
