From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 23 Sep 2015 08:38:12 -0700 From: Tony Lindgren To: Peter Ujfalusi Cc: Michael Turquette , Stephen Boyd , linux-clk@vger.kernel.org, linux-omap@vger.kernel.org, Brian Hutchinson , Felipe Balbi , Grygorii Strashko , Nishanth Menon , Russell King - ARM Linux , Thomas Gleixner , Sekhar Nori Subject: Re: [PATCH] clk: ti: Fix FAPLL udelay in clk_enable with clk_prepare Message-ID: <20150923153812.GF23801@atomide.com> References: <1442956985-32642-1-git-send-email-tony@atomide.com> <560242EB.5070001@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <560242EB.5070001@ti.com> List-ID: * Peter Ujfalusi [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