[PATCH 2/2] ARM: tegra: cpu-tegra: explicitly manage re-parenting
mturquette at ti.com
Tue Sep 11 13:20:34 EDT 2012
Quoting Prashant Gaikwad (2012-09-11 04:39:18)
> On Tuesday 11 September 2012 11:13 AM, Stephen Warren wrote:
> On 09/10/2012 10:45 PM, Mike Turquette wrote:
> Quoting Stephen Warren (2012-09-10 16:12:38)
> From: Stephen Warren <swarren at nvidia.com>
> When changing a PLL's rate, it must have no active children. The CPU
> clock cannot be stopped, and CPU clock's divider is not used. The old
> clock driver used to handle this by internally reparenting the CPU clock
> onto a different PLL when changing the CPU clock rate. However, the new
> common-clock based clock driver does not do this, and probably cannot do
> this due to the locking issues it would cause.
> This is possible today. Clock drivers can call __clk_reparent to update
> the common clk bookkeeping to reflect changes in parent muxing. There
> are some examples of this out in the wild, and the unmerged OMAP port
> certainly uses this during the PLL relock sequence.
> The CPU clock's set_rate needs to both __clk_reparent() /and/ set the
> rate of the parent PLL. I think a (non-static) __clk_set_rate() is
> missing? (although perhaps that could be easily solved if desired).
> To solve this, have the Tegra cpufreq driver explicitly perform the
> reparenting operations itself. This is probably reasonable anyway,
> since such reparenting is somewhat a matter of policy (e.g. which
> alternate clock source to use, whether to leave the CPU clock a child
> of the alternate clock source if it's running at the desired rate),
> and hence is something more appropriate for the cpufreq driver than
> the core clock driver anyway.
> I definitely agree about the policy. Just FYI I'm hacking on an RFC to
> make reparenting clocks from a call to clk_set_rate even easier, but
> perhaps in your case it is better the cpufreq driver knows the clock
> tree topology details.
> OK, sounds fine to me:-)
> Policies can change for Tegra20 and Tegra30. IMO we should implement it in clock driver.
> But it can not be done unless there is a way to call clk_set_rate from clk ops.
OMAP 4460/4470 have a similar constraint to have reparenting operation
depending on the frequency that the ARM runs at. I'll try to implement
this soon and I will Cc you guys on it. Hopefully the same method makes
sense for you.
More information about the linux-arm-kernel