RFC v2: Zynq Clock Controller

[Mike Turquette]

Quoting Sören Brinkmann (2013-03-29 15:36:18)
> On Tue, Mar 26, 2013 at 07:18:44PM -0700, Mike Turquette wrote:
> > As long as a key exists to link two clocks together then registration
> > order shouldn't matter.  Originally this key was an immutable clk name
> > string.
> > 
> > If clock parents are specified in DT then that should also suffice, in
> > place of doing string comparisons.
> > 
> > If no key to pair up clocks exists then yes we will have to rely purely
> > on the struct clk *opaque_cookie and register clocks in order.
> Okay, so I guess, the fundamental mechanisms should be in place. What is
> needed, is changing the key from being the clk name to something else.
> And preferably this something else is made up of something available
> through DT, so a child can reference its parent w/o the parent to be
> probed first. E.g. the provider's node name + the index of the clock
> output?

Right, order shouldn't matter in the sense that registering a child
before a parent should not constitute an absolute failure from the clock
framework point of view.

Folks using DT today still rely on the parent string name to link things
up.  Grep around for usage of of_clk_get_parent_name to see how several
platforms use that during registration.

> You mentioned, something like this was supposed to happen anyway, right?
> Do you already have something specific in mind/are working on a
> solution?
> 

I'm not looking at it currently.  If no one else gets around to it then
eventually I will.  It would be nice to not have to use
of_clk_get_parent_name and instead have a better way to establish
parent-child relationships at clock registration-time for DT clocks.

Regards,
Mike

>         Sören