Re: [PATCH] clk: ti: Fix FAPLL udelay in clk_enable with clk_prepare

[Tony Lindgren <tony@atomide.com>]

* Peter Ujfalusi <peter.ujfalusi@ti.com> [150922 23:17]:
> Tony,
> 
> On 09/23/2015 12:23 AM, Tony Lindgren wrote:
> > As recently pointed out (again) by Thomas and Russell, we must not
> > wait in in clk_enable. The wait for PLL to lock needs to happen
> > in clk_prepare instead.
> > 
> > It seems this is a common copy paste error with the PLL drivers,
> > and similar fixes should be applied to other PLL drivers after
> > testing.
> 
> One thing to note:
> because of how the hwmod code works, at boot time we prepare all clocks for
> the devices and in runtime the hwmod only uses clk_enable/disable, it will
> never unprepare the clock(s). This will means that these clocks will be
> enabled all the time and will never turned off.

Good point, we need to check that for hwmod pm_runtime related
functions. Basically the PLLs we can't disable until in
pm_runtime_disable.

I think the approach we need to take to be that clk_enable/disable
is really optional clk_gate_enable/disable. And in many cases PLLs
don't have a gate, so it's correct for pm_runtime enable/disable
to not do anything for the PLLs.

And the reason we don't want to change pm_runtime hooks to use
clk_prepare_enable/disable is that then drivers can't use
pm_runtime_irq_safe like some do currently.

Regards,

Tony