[PATCH RFC] clk: add support for automatic parent handling

[Russell King - ARM Linux]

On Fri, Apr 29, 2011 at 01:11:25PM +0200, Thomas Gleixner wrote:
> I tend to disagree. Yes, he created the minimal common level for a
> struct clk and the ops around it. But does that change anything about
> the status quo of duplicated functions walking the tree, duplicated
> functions to validate and round clock rates? The whole approach will
> keep the whole code mess in the SoCs the same as it is now and just
> enforce a common data structure and a dozen wrapper "API" functions
> around it.
> 
> So omap will simply have their bloat in a struct omap_clk() and every
> other SoC will do the same. The duplicated code, the locking mess
> etc. will all remain in totally incompatible ways. So what's the win?

I disagree.  With a 'divider+mux' clk, OMAP can move those clocks
over.  With a 'pll' clk, OMAP can move the PLL stuff over.  With a
simple enable/disable clk, OMAP can move those over.  That's a
significant portion of the OMAP clk mess converted over to smaller,
much more well defined, self contained clk structures.

I don't see any reason with this why OMAP - or anyone else - should
have their own platform_clk structure if we have the necessary building
blocks, and provided there is sufficient review to ensure that those
building blocks which are found to be lacking get fixed along the way.

As for the locking mess, that's what happens when you try to generalize
stuff and end up with a finer locking scheme.  The more locks you have,
the more complex the locking rules become, and the more problems you
encounter with potential deadlocks.  And it seems that lockdep also
starts to struggle too (as it operates on classes of locks not actual
locks.)