moving Tegra30 to the common clock framework
Peter De Schrijver
pdeschrijver at nvidia.com
Wed May 9 06:36:07 EDT 2012
On Wed, May 09, 2012 at 02:41:37AM +0200, Saravana Kannan wrote:
> On 05/08/2012 10:15 AM, Turquette, Mike wrote:
> > On Mon, May 7, 2012 at 10:07 PM, zhoujie wu<zhoujiewu at gmail.com> 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.
>
We also need to reparent clocks using a pll if we want to change the PLLs rate
while the users are active.
Cheers,
Peter.
More information about the linux-arm-kernel
mailing list