On Mon, Sep 10, 2012 at 09:45:30PM -0700, Mike Turquette wrote:

quoted

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.

I disagree.  The whole point of clock framework is to hide clock details
like tree topology behind clock API, so that we do not need every single
clock client driver to handle those details on their own.  It's
definitely desired to have clk_set_rate call handle reparenting nicely.

From what I see, if tegra clock driver can handle the dependency between

cpu_clk and emc_clk that is currently handled in cpufreq driver.  It's
likely that the generic cpufreq driver (cpufreq-cpu0) would work for
tegra.  But with this patch, the driver moves to the opposite direction.

Regards,
Shawn