Re: [PATCH 0/5] Clocklib: generic clocks framework

Paul Walmsley
2008-04-21T07:51:06Z

Hello Dmitry,

By way of introduction, I've been working on the Linux-OMAP clock tree
over the past several months. I recently had the opportunity to take a
brief look at these clocklib patches that you're posting, and had a few
thoughts:

- I understand from the discussions in this thread that the usage of your
clocklib code will be optional. However, the way you implement various
parts of the clock interface may effectively become mandatory, and
clocklib may not be able to handle many of the platform-specific clock
details that are necessary with more complex clock layouts like OMAP.
Would you consider the main goal of your clocklib code to be simply the
removal of several of the simpler ARM clock tree implementations? Or is
your intention for it to ultimately replace all of the current Linux
clock implementations? If the latter, your patchset will presumably
need a higher standard of review, since once it is integrated, any
changes will affect several architectures, rather than simply one.

- As others have mentioned earlier on this thread, it seems difficult to
construct a good "one-size-fits-all" struct clk. At the very least,
I would also suggest adding a 'void *' to allow storage of clock-specific
data.

- Hiroshi DOYU has proposed an alternate debugfs implementation for the
Linux-OMAP clock tree. I prefer it to yours, as it implements each
clock as a separate dentry, which makes it easy to implement additional
debugging functions, such as set_rate/set_parent/round_rate debugging.
Perhaps you'd consider it, or something similar to it, instead? It is
proposed here:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg00751.html

- I don't think that I understand the clk_functions part of your code.
Is this a shorthand to construct aliases to other struct clks?

regards,

- Paul