moving Tegra30 to the common clock framework

[Peter De Schrijver]

On Sun, May 13, 2012 at 06:31:42AM +0200, Stephen Warren wrote:
> On 05/11/2012 08:58 PM, Saravana Kannan wrote:
> > On 05/09/2012 03:36 AM, Peter De Schrijver wrote:
> >> 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.
> > 
> > Peter,
> > 
> > Is this reparent permanent (as in, stays reparented when you return from
> > clk_set_rate()) or is it a reparenting for just a short duration inside
> > the set_rate ops?
> 
> I've seen both cases, and indeed the case sometimes depends on the
> target rate of the clock.
> 
> For example, when the CPU clock changes, we basically do the following
> within set_rate:
> 
> * Set CPU clock parent to some "backup" PLL
> * Change the CPU PLL to the desired rate
> * Set CPU clock parent to the CPU PLL
> 
> However, the lowest CPU clock rate we support is actually the rate that
> the backup PLL runs at, so if we're targeting that rate, the CPU clock
> set_rate /just/ does:
> 
> * Set CPU clock parent to some "backup" PLL
> 
> and leaves it there, until a different CPU clock rate is requested, at
> which time the CPU clock will be re-parented back to the CPU PLL.

The backup PLL and rate are statically defined however. It's not chosen at
runtime.

Cheers,

Peter.