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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Peter Ujfalusi <peter.ujfalusi@xxxxxx> [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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux