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

[Russell King - ARM Linux]

On Fri, Apr 29, 2011 at 12:51:44PM +0200, Thomas Gleixner wrote:
> On Fri, 29 Apr 2011, Russell King - ARM Linux wrote:
> 
> > On Wed, Apr 20, 2011 at 09:52:15PM +0200, Thomas Gleixner wrote:
> > > On Wed, 20 Apr 2011, Uwe Kleine-König wrote:
> > > > struct clk has no parent member, there is only clk_get_parent(). If
> > > 
> > > Which is a complete failure to begin with. Why the heck do you need a
> > > callback to figure that out?
> > 
> > Thomas, you're wrong.  You're looking at things far too simply, because
> > all you can see is a tree of clocks.
> 
> And that's what it is. Even if the clock can have sevaral possible
> parents, then there is only one active parent at a time. It's still a
> tree.
>  
> > When you have MUXes, a clock can have one of many parents.  So a single
> > clk->parent doesn't hack it.  That's one reason why clk_get_parent()
> > exists, so that MUXes can return the appropriate parent for the current
> > MUX setting.
> 
> That's only ever needed when you register a clk with the framework to
> decode the current setting from the hardware.
>  
> > You may wish to store the current setting in clk->parent, but I'd argue
> > that's a recipe for things going wrong when the MUX settings differ from
> > the cached clk->parent value.  Instead, having clk_get_parent()s
> > implementation return the _current_ parent and let MUXes do the right
> > thing depending on hardware is much easier and more reliably correct.
> 
> If something changes the clk parent in the hardware without going
> through common framework functions, which take care of updating
> clk->parent in the proper way, then the implementer got it wrong
> badly. That's the same thing as if you change the clock rate of your
> timekeeping clock behind the timekeeping core and then complain about
> timekeeping going awry.

No, the question is whether you cache the parent clock in a pointer,
or use an abstraction to obtain the parent clock.  It's merely an
implementation detail and is not as big a problem as you've been
trying to make it out to be.