Re: moving Tegra30 to the common clock framework

[Saravana Kannan <skannan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]

On 05/08/2012 10:15 AM, Turquette, Mike wrote:
> On Mon, May 7, 2012 at 10:07 PM, zhoujie wu<zhoujiewu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>  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.