From patchwork Tue Dec 8 21:52:45 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 7802411 X-Patchwork-Delegate: rjw@sisk.pl Return-Path: X-Original-To: patchwork-linux-pm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 0A7E6BEEE1 for ; Tue, 8 Dec 2015 21:53:39 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4AC86203E9 for ; Tue, 8 Dec 2015 21:53:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 70E2E203C3 for ; Tue, 8 Dec 2015 21:53:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750841AbbLHVxX (ORCPT ); Tue, 8 Dec 2015 16:53:23 -0500 Received: from mout.kundenserver.de ([212.227.126.130]:52742 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750769AbbLHVxW (ORCPT ); Tue, 8 Dec 2015 16:53:22 -0500 Received: from wuerfel.localnet ([134.3.118.24]) by mrelayeu.kundenserver.de (mreue002) with ESMTPSA (Nemesis) id 0M6alo-1aRNPp147Q-00wWMB; Tue, 08 Dec 2015 22:52:49 +0100 From: Arnd Bergmann To: linux-pm@vger.kernel.org Cc: "Rafael J. Wysocki" , Viresh Kumar , Stephen Warren , Thierry Reding , Alexandre Courbot , linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, broonie@kernel.org, Liam Girdwood Subject: [PATCH] cpufreq: tegra: add regulator dependency for T124 Date: Tue, 08 Dec 2015 22:52:45 +0100 Message-ID: <2194927.eV2s2QmZs0@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) MIME-Version: 1.0 X-Provags-ID: V03:K0:+wMoEJf6KlitdlyXqKoweOznbu7plT+VT0WevNSL8S61QoKxWAo LHWfDtrbJCxgAaKLKb1HOCvSIhAw/OZd/TuBdRoHYYw1zA6tw390R9ZhgCCEjH4bH+mP9vv sMX2WzydhbqoPpkF6tnPEbJi5VmN2ySyQ5XqljLdz2SdaAFW6m80VI68l+tqseBbsk4BRoV dpWIQS2eWqSlnjIou/wNw== X-UI-Out-Filterresults: notjunk:1; V01:K0:E1JHN/t+oe8=:je0FMEjvWepQRlenBXeef5 mnCG90iIH97vEYk8uDymK1RKOmbif4UE/6dr0wTXhq99ni+FWo4B77enP1OHvRoYq+XjXeABD 7VKtb5mLp6gkOUoMfG/8f++D2EzeKdYGGNRGVwd6J1O3CTzSoYY8dWPC3Kr7gURQv7YAWhr/X Ue0Enh4wynEgK75/iTi6ghtSK8mva7XYGeUSWckwgPWGUbXgg4k7EoslnTszdTIUEuGRlFezF iqh8f+OaZSes583VVBJ1hn3OAbMXtXkc6VhMUvme7BF51ofFMqFTt9/BwhQv3aNhofkU3Jk3+ lkbcBzJO8RTVEdwLRrVHxzNJr/KmnpdoUINmBGbE5wbtCSyU/PhYP9ZntkSvtuKMWYaX0I3ck 3foGzyWdGUgcVTnrvX2xgGF0cxRE5+8vQYaQtwobXH81ZR6lEaI1l8vWO7c6WUAucD/a/I/Fz Ejl+AsAKZV2tgJl6ogbvMNV1n4tjMHXrxw8I023Nct5Df139UZgVtsra3KGGillVdnOjg0f8v 4MMFBMWgHdXGnkyH55PYMQLark8mYxD4eC2BTg9lDYPVuo1EY0cdjIniDg43WeNJSx2fneBKF OSh8GA/VcWFuIp1YUILGExNevEG+zhSPm0mWMpSsfEWyzYm260zWhIon/3gyV6LgjijPvKNlP /oR7KFQQu1wnHVJgT/X8W8x+NMsK5qbwhkab8pD1jEjJr//85YU37mRlxLDyRYRnIYx2z4udn oXo1yX36A8EVrzXX Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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. 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 Acked-by: Viresh Kumar Acked-by: Jon Hunter --- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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.