Re: OMAP CLK / CM data move to /drivers/clk

[Mike Turquette <mturquette@linaro.org>]

Quoting Tero Kristo (2013-02-27 00:44:19)
> Hi Paul and Mike,
> 
> It looks like we need to start putting more effort into this clock data
> move now, as this is starting to hinder us on several fronts.
> Unfortunately I still can't personally participate in this work myself
> as I am now allocated to some hwmod related work, but Eduardo should
> have plenty of time to help with this...
> 
> Anyway, Paul, I think you have been working a bit with this topic, what
> is the latest status with this? Do you see any areas Eduardo can help
> with? If you have some partially finished work also which you don't have
> time yourself, we can even take a look at that.
> 
> Also, I would like to receive some initial comments about the approach
> we should take, and I added Mike here for this as you are the maintainer
> for the /drivers/clk. I believe we should start by moving the clock data
> under /drivers/clk/omap, and potentially move also some other stuff
> here, like CM code, clockdomain code and clockdomain data even. Do you
> have any opinions on this?
> 

My gut reaction is that I do not want the clockdomain or CM code under
drivers/clk.  The clock code and data is welcome under drivers/clk.  If
there are zero users of the CM and clockdomain code outside of the clock
code, then I'll consider it, but otherwise the CM and clockdomain code
must find a proper home.

There was some discussion about a general place to put power controller
code [1] and some stuff about power sequencing on the list [2], perhaps
that is a better destination for the CM and clockdomain code?  I admit
it is a stretch.

There are two other points to consider when migrating this data:

1) Has the hwmod initialization been changed to run after early init,
when slab is up?  If so then that removes the barrier keeping the OMAP
clock data statically initialized via clk-private.h.  Whoever is going
to migrate this data should think about registering the clocks
dynamically and using clk-provider.h instead of clk-private.h.  I'd like
to remove the latter header and after Tegra's latest CCF patches I
believe that only OMAP is making use of it.

2) Migrating the clock data to device tree.  This seems to be the way
everyone is going.  I care less about this one as the maintainer of
drivers/clk and more about getting rid of clk-private.h users once and
for all.

Regards,
Mike

[1] http://article.gmane.org/gmane.linux.ports.arm.omap/90425
[2] http://article.gmane.org/gmane.linux.kernel/1395912/match=runtime+interpreted+power+sequences

> -Tero