[RFC 00/24] Move OMAP2+ over to use COMMON clock

[jon-hunter@ti.com (Jon Hunter)]

Hi Rajendra,

On 06/04/2012 03:52 AM, Rajendra Nayak wrote:
> Hi Jon,
> 
> On Saturday 02 June 2012 04:57 AM, Jon Hunter wrote:
>> Hi Rajendra,
>>
>> On 06/01/2012 07:07 AM, Rajendra Nayak wrote:
>>> Hi,
>>>
>>> This RFC series is based of Mikes' latest clk-next. I will
>>> rebase it once 3.5-rc1 is out and post with more testing thats
>>> in progress. Meanwhile, the RFC is for me to get some early
>>> feedback on the patches.
>>>
>>> This series retains the static clock declarations and also
>>> all data and code in mach-omap folders and does not move
>>> it as yet to drivers/clk. I know its desierable that we move
>>> away from static declaration of data and move over to drivers/clk
>>> but thats not addressed by this series.
>>> Also the series moves over only OMAP2+ (OMAP2/3/4)
>>> to use COMMON clk and leaves OMAP1 still using OMAP
>>> clock framework.
>>>
>>> The series does not break git-bisect at any point and to
>>> do so adds new data in completely different files and uses
>>> some ifdefferry in code too, and switches over in one
>>> patch to move from OMAP clock to COMMON clock. Then deletes
>>> all old data files and all the ifdeferrey around.
>>>
>>> All of the new data for OMAP2/3/4 in the new COMMON clock
>>> format is autogenerated, OMAP4 by hacking the existing python
>>> scripts, and OMAP2/3 by converting the existing C99 structs
>>> to JSON format (Thanks to Paul Walmsley for this) and then having
>>> python to read the JSON format and generate the C99 structs
>>> back in the form COMMON clk expects.
>>>
>>> The patches also depend on 2 of my patches posted here
>>> http://comments.gmane.org/gmane.linux.kernel/1298747
>>> I have not reposted them becasue one of them is already
>>> picked up by Mike, and the other is already under discussion.
>>>
>>> The series with all dependent patches can be found here
>>> git://github.com/rrnayak/linux.git clk-next-omap
>>>
>>> regards,
>>> Rajendra
>>>
>>> Mike Turquette (1):
>>>    ARM: omap4: cm: add bitfield width values
>>>
>>> Rajendra Nayak (23):
>>>    clk: Add CLK_IS_BASIC flag to identify basic clocks
>>>    ARM: omap: clk: convert all clk_enable to clk_prepare_enable
>>>    ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
>>>    ARM: omap: clk: Nuke plat clock.c&  clock.h if CONFIG_COMMON_CLK
>>>    ARM: omap: clk: Remove all direct dereferncing of struct clk
>>>    ARM: omap: hwmod: Fix up hwmod based clkdm accesses
>>>    ARM: omap4: clk: Convert to common clk
>>>    ARM: omap3: clk: Convert to common clk
>>>    ARM: omap2: clk: Convert to common clk
>>>    ARM: omap: clk: list all clk_hw_omap clks to enable/disable autoidle
>>>    ARM: omap: clk: Define a function to enable clocks at init
>>>    ARM: omap4: clk: Add 44xx data using common struct clk
>>>    ARM: omap3: clk: Add 3xxx data using common struct clk
>>>    ARM: omap2: clk: Add 24xx data using common struct clk
>>>    ARM: omap: clk: Switch to COMMON clk
>>>    ARM: omap: clk: Use plat clock.c&  clock.h only for OMAP1
>>
>> With regard to the above patch, I am not sure why it is necessary to
>> move the existing definitions out of plat-omap/clock.h to put in
>> mach-omap2/clock.h. Eventually, if we move omap1 to the common clock
>> framework, won't we need to move them back? It would seem to me that by
>> keeping them in plat clock.h it will be easier to migrate omap1 to the
>> common clock framework (assuming thats our goal). Also, by adding the
>> common clock definitions to the plat clock.h it will be easier for
>> migrating omap1 too.
> 
> I was infact thinking of moving these files into mach-omap1/ since they
> are now OMAP1 specific. Is your concern coming mainly from the clksel
> structs that you will need to be shared across OMAP1 and OMAP2+?

Yes, especially if we plan to move omap1 to the common clock framework.

> The right thing to do seems like is to move OMAP1 across to COMMON clk
> also and keep the plat clock.h and get rid of plat clock.c completely.
> But for now, I really haven;t looked at OMAP1 migration as all.

Yes that would make sense. Do you have plans to do this or not yet?

Cheers
Jon