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

[Thomas Gleixner]

On Fri, 29 Apr 2011, Russell King - ARM Linux wrote:
> 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.

Agreed. But that's an orthogonal problem to the proper handling of the
tree walks, propagation of rates, enable, prepare etc. and common
validation functions.
 
> 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.)

The per clk locking is not going to work ever except you want to have
the trylock dance if you need to propagate changes up the tree and
down the tree. So yes, we need per tree locking and I can see the need
for the mutex and the spinlock to protect the tree, but you really
want to have the logic dealing with those locks and how they both
protect the tree in common code and not in some random place.

Thanks,

	tglx