On 20120508-19:20, skannan at codeaurora.org wrote:

quoted

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

quoted

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