On 20120508-19:20, skannan@xxxxxxxxxxxxxx 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 -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
