[PATCH 04/10] clk: implement parent pass through functions

[tglx@linutronix.de (Thomas Gleixner)]

On Wed, 20 Apr 2011, Uwe Kleine-K?nig wrote:

> On Tue, Apr 19, 2011 at 11:54:21PM +0200, Thomas Gleixner wrote:
> > On Tue, 19 Apr 2011, Uwe Kleine-K?nig wrote:
> > > > +1 for letting the core enable/disable and prepare/unprepare the parent
> > > > clocks. I scanned the different arm clock implementations and they all
> > > > do it, except the ones which do not implement parents at all.
> > > Then the question is if all do handle parents in the same way. (i.e.
> > > in enable do parent first, in disable do child first?)
> > 
> > That's not a question at all. Anything which does it the other way
> > round is broken. Period.
> I havn't checked, but I remember Jeremy not wanting to handle parents in
> the generic part because he saw some differences.

It does not matter whether you checked or not. And it does not matter
whether Jeremy found code which does it the other way round.

The only safe way is parent first on enable and child first on
disable. That's a matter of hardware and not a question of random Joe
hacker got it wrong and it happens to work.

Sure it works on a simple divider which is connected to the parent
clock, but think "child is a PLL".

So having a strict ordering enforced is the only sane way, unless you
can prove that a particular piece of hardware requires it the other
way round. And I doubt that you can find one.

So the framework should be coded for the sane case in the first
place. If the unlikely case of reverse ordering surfaces one day, then
it's not rocket science to deal with that with a flag in struct clk
which tells clk_enable/disable or prepare/unprepare to do it the other
way round.

Thanks,

	tglx