From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Hunter Subject: Re: [RFC 00/24] Move OMAP2+ over to use COMMON clock Date: Mon, 4 Jun 2012 08:51:34 -0500 Message-ID: <4FCCBD66.2080504@ti.com> References: <1338552485-31325-1-git-send-email-rnayak@ti.com> <4FC94FC9.9070903@ti.com> <4FCC7737.8070201@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Return-path: Received: from bear.ext.ti.com ([192.94.94.41]:46706 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752641Ab2FDNvk (ORCPT ); Mon, 4 Jun 2012 09:51:40 -0400 In-Reply-To: <4FCC7737.8070201@ti.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Rajendra Nayak Cc: mturquette@ti.com, paul@pwsan.com, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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