[RFC v2 4/9] of: add clock providers

[Turquette, Mike]

On Thu, Jan 12, 2012 at 2:07 AM, Jamie Iles <jamie at jamieiles.com> wrote:
> On Wed, Jan 11, 2012 at 09:46:58PM -0700, Grant Likely wrote:
>> On Tue, Jan 10, 2012 at 2:33 PM, Jamie Iles <jamie at jamieiles.com> wrote:
>> > On Mon, Dec 12, 2011 at 03:02:04PM -0700, Grant Likely wrote:
>> > I'm about to start trying to get this and Mike's common struct clk
>> > patches working on picoxcell, and the one thing I'm not understanding at
>> > the moment is how to handle the tree itself.  Currently I was planning
>> > on iterating over all clocks and finding a named input clock "ref" or
>> > "input" perhaps.  This would be fine for picoxcell, but I guess more
>> > complicated chips may need something else.
>>
>> It might be useful to have something like of_irq_init() for setting up
>> initial clocks, but the solution feels inelegant to me.  I suspect
>> that there will be end up being intertwined init order dependencies
>> between clocks and irqs and other early setup stuff that could be
>> handled better.  Again, I need to think about this some more.  There
>> might need to be something like an of_early_probe() call that accepts
>> a match table of compatible values and setup functions with some logic
>> or data to resolve dependencies.  The trick will be to not end up with
>> something complex.  I'll need to think about this more...
>
> Yes, probably not an easy problem to solve, especially for the platforms
> where the parent can change at runtime.
>
> I wonder if an of_clk_init() could take a platform callback, so that
> of_clk_init() goes of and creates a struct clk for each clk in the DT,
> then for each registered clock calls a platform specific callback which
> returns the parent (if any).  It feels like a fairly platform specific
> problem to me.

Based on Thomas' feedback I'm removing the requirement for clocks to
be registered in-order with clk_init().  Any clock that cannot resolve
it's parent within clk_init() (via the .get_parent callback, or
otherwise having .parent statically initialized) will be put into an
orphaned clocks list, which will be walked every time a new clock is
registered.  Hurray for n^2 solutions.

Does the above help with the of_clk_init problems?

One final data point: I certainly plan on allowing for statically
allocated clocks to live alongside DT clocks.  In fact the clock trees
on OMAP are so large that there is some discussion about having some
of the clocks statically allocated and some in DT, but I don't know
what that split looks like right now.  I don't enjoy the idea of
packing 200+ of any entity into a .dts blob.

Regards,
Mike