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

Russell King - ARM Linux
2011-04-29T10:56:08Z

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.