OMAP CLK / CM data move to /drivers/clk

OMAP CLK / CM data move to /drivers/clk

[Tero Kristo]

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?

-Tero

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

[Eduardo Valentin]

On 27-02-2013 04:44, Tero Kristo wrote:
> 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...

hehe.. That's a bit stretching, but yes, I can help with this move :-)

>
> 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.
Paul,

Couple of initial questions. Would we move also the existing CM / PRM 
code? Is there any cross dependency with SCM?

Paul, would be you who would be queuing these changes?

>
> 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?
>
> -Tero
>
>
>
>

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

[Mike Turquette]

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

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

[Eduardo Valentin]

Mike,

On 27-02-2013 14:43, Mike Turquette wrote:
> 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.

The documentation under "Documentation/clk.txt" states somewhat different:
"
To get around this problem struct clk's definition is exposed in
include/linux/clk-private.h along with some macros for more easily
initializing instances of the basic clock types.  These clocks must
still be initialized with the common clock framework via a call to
__clk_init."

Despite the fact that OMAP is the only real user of clk-private.h, I 
believe one must update the documentation to clear discourage the usage 
of clk-provider.h by any means, outside the core CCF code, even for 
static definition of clk data, considering your statement above.

>
> 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.

Tegra folks has already stepped into that direction. I agree that this 
is ideal for declaring the clock static data. This is obviously more 
complicated for OMAP legacy code. That would need to be done into two 
steps at least, so that we won't break support on older OMAP versions.

>
> 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
>
>

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

[Paul Walmsley]

Hi guys,

On Wed, 27 Feb 2013, Tero Kristo wrote:

> 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?

Will respond soon to this...

- Paul