Messages in this thread |  | | Date | Mon, 21 Apr 2008 01:44:12 -0600 (MDT) | From | Paul Walmsley <> | Subject | Re: [PATCH 0/5] Clocklib: generic clocks framework |
| |
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
|  |