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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
