On Thu, Jan 12, 2012 at 2:07 AM, Jamie Iles <jamie@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@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 tobe registered in-order with clk_init(). Any clock that cannot resolveit's parent within clk_init() (via the .get_parent callback, orotherwise having .parent statically initialized) will be put into anorphaned clocks list, which will be walked every time a new clock isregistered. 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 staticallyallocated clocks to live alongside DT clocks. In fact the clock treeson OMAP are so large that there is some discussion about having someof the clocks statically allocated and some in DT, but I don't knowwhat that split looks like right now. I don't enjoy the idea ofpacking 200+ of any entity into a .dts blob.