OMAP CLK / CM data move to /drivers/clk
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
Quoted 7 lines · 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...
hehe.. That's a bit stretching, but yes, I can help with this move :-)
Quoted 5 lines
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?
Quoted 13 lines
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
Quoting Tero Kristo (2013-02-27 00:44:19)
Quoted 13 lines
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.
Quoted 7 lines
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
Quoted 1 line
-Tero
Mike,
Quoted 35 lines · Mike Turquette
Quoting Tero Kristo (2013-02-27 00:44:19)
Quoted 13 lines
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.
Quoted 7 lines
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 underdrivers/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:
Quoted 7 lines
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 usingclk-provider.hinstead ofclk-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.
Quoted 5 lines
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/clkand more about getting rid ofclk-private.husers 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.
Quoted 10 lines
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+sequencesQuoted 1 line
-Tero
Hi guys,
Quoted 11 lines · Tero Kristo
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.
Quoted 6 lines
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