From mboxrd@z Thu Jan 1 00:00:00 1970 From: Saravana Kannan Subject: Re: moving Tegra30 to the common clock framework Date: Tue, 08 May 2012 17:41:37 -0700 Message-ID: <4FA9BD41.2090701@codeaurora.org> References: <20120503161311.GG20304@tbergstrom-lnx.Nvidia.com> <20120507000329.GB14559@gmail.com> <4FA7ECAA.1040104@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "Turquette, Mike" Cc: zhoujie wu , Stephen Warren , linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Peter De Schrijver , paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: linux-tegra@vger.kernel.org On 05/08/2012 10:15 AM, Turquette, Mike wrote: > On Mon, May 7, 2012 at 10:07 PM, zhoujie wu wrote: >> Hi Mike, >> Could you please explain more details about how to implement a >> re-parenting operation as part of it's .set_rate implementation? > > Sure. > >> As far as I know, we can not call clk_set_parent in .set_rate function >> directly, since clk_set_rate and clk_set_parent are using the same >> prepare_lock. > > That is correct. > >> Any other interface can be used to implement it? > > You have two options available to you. > > 1) __clk_reparent can be used from your .set_rate callback today to > reflect changes made to the tree topology. OMAP uses this in our PLL > .set_rate implementation: depending on the re-lock frequency the PLL > may switch parents dynamically. __clk_reparent does the > framework-level cleanup needed for this (that function is also used > when populating the clock tree with new clock nodes). > > 2) __clk_set_parent could be made non-static if you needed this (I've > been meaning to talk to Saravana about this since I think MSM needs > something like this). Thanks! I don't think I need (2). But I don't think I can use (1) as is either. I can use (1) with some additional code in my set rate op. While set rate is in progress, both the parents might need to stay enabled for a short duration. So, in my internal set rate, I need to check if my clock is prepared/enabled and call prepare/enable on the "old parent", call __clk_reparent (which will reduce the ref count for the old parents and increase it for the new parents), finish the reparent in HW and then unprepare/disable the old parent if I have prepared/enabled them earlier. It might be beneficial to provide something like a __clk_reparent_start(new_parent, *scratch_pointer) and __clk_reparent_finish(*scratch_pointer) if it will be useful for more than just MSM. Based on this email, I would guess that Tegra would want something similar too. Thanks, Saravana -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.