moving Tegra30 to the common clock framework

[Turquette, Mike]

On 20120508-19:20, skannan at codeaurora.org wrote:
> > 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.
> >

The .set_rate implemenation for OMAP's PLLs has the same requirement and
this is handled by nested calls to __clk_prepare and clk_enable.  Please
refer the omap3_noncore_dpll_set_rate definition:

http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=blob;f=arch/arm/mach-omap2/dpll3xxx.c;h=63e92e2d4bb80ea702572b919c17b0ac9f93cc0e;hb=clk-next-omap#l425

> > 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.
>
> Thinking more about this, I think this is how any clk op that might change
> the parent should operate. I will try to write up an RFC patch for this
> and send it out soon. I'm in a hurry, so will explain more in the RFC
> patch or in a later email.

I'm interested to see your patch, as I might not be fully understanding
your requirements.  Is there any reason why making nested calls to
__clk_prepare and clk_enable from your .set_rate callback isn't enough?

Thanks,
Mike