Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754051AbbLIMDg (ORCPT ); Wed, 9 Dec 2015 07:03:36 -0500 Received: from hqemgate14.nvidia.com ([216.228.121.143]:9118 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752467AbbLIMDe (ORCPT ); Wed, 9 Dec 2015 07:03:34 -0500 X-PGP-Universal: processed; by hqnvupgp07.nvidia.com on Wed, 09 Dec 2015 03:49:44 -0800 Subject: Re: [PATCH] cpufreq: tegra: add regulator dependency for T124 To: Arnd Bergmann , References: <2194927.eV2s2QmZs0@wuerfel> CC: "Rafael J. Wysocki" , Viresh Kumar , Stephen Warren , "Thierry Reding" , Alexandre Courbot , , , , , Liam Girdwood From: Jon Hunter Message-ID: <5668188F.2080202@nvidia.com> Date: Wed, 9 Dec 2015 12:03:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <2194927.eV2s2QmZs0@wuerfel> X-Originating-IP: [10.21.132.159] X-ClientProxiedBy: UKMAIL102.nvidia.com (10.26.138.15) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3072 Lines: 67 Hi Arnd, On 08/12/15 21:52, Arnd Bergmann wrote: > This driver is the only one that calls regulator_sync_voltage(), but it > can currently be built with CONFIG_REGULATOR disabled, producing > this build error: > > drivers/cpufreq/tegra124-cpufreq.c: In function 'tegra124_cpu_switch_to_pllx': > drivers/cpufreq/tegra124-cpufreq.c:68:2: error: implicit declaration of function 'regulator_sync_voltage' [-Werror=implicit-function-declaration] > regulator_sync_voltage(priv->vdd_cpu_reg); > > My first attempt was to implement a helper for this function > for regulator_sync_voltage, but Mark Brown explained: > > We don't do this for *all* regulator API functions - there's some where > using them strongly suggests that there is actually a dependency on > the regulator API. This does seem like it might be falling into the > specialist category [...] > Looking at the code I'm pretty unclear on what the authors think the > use of _sync_voltage() is doing in the first place so it may be even > better to just remove the call. It seems to have been included in the > first commit so there's not changelog explaining things and there's > no comment either. I'd *expect* it to be a noop as far as I can see. In this sequence we are switching from the DFLL clock source (which directly controls the voltage) back to a PLL (which does not control the voltage directly). What we want to do is to restore the voltage back to the voltage it was operating at before we switched to the DFLL clock (which could have changed it). I am not familiar with regulator_sync_voltage() but from the comment it does say that it will re-apply the last voltage that was configured for the regulator. So I can see what they were doing. The question I have is, if the consumer has not explicitly called regulator_set_voltage() then what does regulator_sync_voltage() do? I am wondering if we should have been doing a regulator_get_voltage() during the probe and a regulator_set_voltage() when switching back? > This adds the dependency to make the driver always build successfully > or not be enabled at all. Alternatively, we could investigate if the > driver should stop calling regulator_sync_voltage instead. > > Signed-off-by: Arnd Bergmann > > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm > index 235a1ba73d92..b1f8a73e5a94 100644 > --- a/drivers/cpufreq/Kconfig.arm > +++ b/drivers/cpufreq/Kconfig.arm > @@ -226,7 +226,7 @@ config ARM_TEGRA20_CPUFREQ > > config ARM_TEGRA124_CPUFREQ > tristate "Tegra124 CPUFreq support" > - depends on ARCH_TEGRA && CPUFREQ_DT > + depends on ARCH_TEGRA && CPUFREQ_DT && REGULATOR > default y > help > This adds the CPUFreq driver support for Tegra124 SOCs. Acked-by: Jon Hunter Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/