From patchwork Sat Dec 17 09:29:29 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 5834 Return-Path: X-Original-To: patchwork@peony.canonical.com Delivered-To: patchwork@peony.canonical.com Received: from fiordland.canonical.com (fiordland.canonical.com [91.189.94.145]) by peony.canonical.com (Postfix) with ESMTP id 2F40E23E10 for ; Sat, 17 Dec 2011 09:31:46 +0000 (UTC) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by fiordland.canonical.com (Postfix) with ESMTP id 1E2E5A185EC for ; Sat, 17 Dec 2011 09:31:46 +0000 (UTC) Received: by eeke52 with SMTP id e52so4323245eek.11 for ; Sat, 17 Dec 2011 01:31:46 -0800 (PST) Received: by 10.14.32.20 with SMTP id n20mr932287eea.42.1324114305905; Sat, 17 Dec 2011 01:31:45 -0800 (PST) X-Forwarded-To: linaro-patchwork@canonical.com X-Forwarded-For: patch@linaro.org linaro-patchwork@canonical.com Delivered-To: patches@linaro.org Received: by 10.204.173.131 with SMTP id p3cs11915bkz; Sat, 17 Dec 2011 01:31:45 -0800 (PST) Received: by 10.14.95.140 with SMTP id p12mr900406eef.105.1324114303632; Sat, 17 Dec 2011 01:31:43 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de. [212.227.126.186]) by mx.google.com with ESMTP id a59si1170874eeb.22.2011.12.17.01.31.43; Sat, 17 Dec 2011 01:31:43 -0800 (PST) Received-SPF: neutral (google.com: 212.227.126.186 is neither permitted nor denied by best guess record for domain of arnd@arndb.de) client-ip=212.227.126.186; Authentication-Results: mx.google.com; spf=neutral (google.com: 212.227.126.186 is neither permitted nor denied by best guess record for domain of arnd@arndb.de) smtp.mail=arnd@arndb.de Received: from wuerfel.localnet (port-92-200-73-161.dynamic.qsc.de [92.200.73.161]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LodLS-1R5Z1p1LHm-00giQ8; Sat, 17 Dec 2011 10:29:35 +0100 From: Arnd Bergmann To: linaro-dev@lists.linaro.org Cc: Richard Zhao , Rob Herring , linux@arm.linux.org.uk, patches@linaro.org, devicetree-discuss@lists.ozlabs.org, cpufreq@vger.kernel.org, eric.miao@linaro.org, kernel@pengutronix.de, davej@redhat.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH V2 1/4] cpufreq: add arm soc generic cpufreq driver Date: Sat, 17 Dec 2011 10:29:29 +0100 Message-ID: <1771359.4jv0xX1vFp@wuerfel> User-Agent: KMail/4.7.2 (Linux/3.1.0-rc8nosema+; KDE/4.7.2; x86_64; ; ) In-Reply-To: <20111217080001.GC2010@richard-laptop> References: <1324031462-24961-1-git-send-email-richard.zhao@linaro.org> <4EEB5683.7000409@gmail.com> <20111217080001.GC2010@richard-laptop> MIME-Version: 1.0 X-Provags-ID: V02:K0:sV2HYMbrG0s1Jo5n9J8GVsnK1ZWuwTzOfuzycfw3OWo LhTAQqVq42jwxjRF0FAaHlgRc3Xg6Q5XParErNl+XfWm0CqGeS foHt2+N7dH4m7O8eDX/I9jk7dxPqFFOGtzZeDAvh1vuCl1xfvV RxpMarLjPnVAGXWA4TVpbslPKRTnJHy1bjm1//sh1ow9Z6/8L4 vZ4NMnUjEVmKa05vlLSEOm1MfR/WhUjlVmPNCHjy4yXEgkCvEh WhvUXi4iK0dnmB0LBO1kwTHvD2yojKlftEZZ6FSSLv40iTCMj6 AdBeggzOV1D00q5GZX3Bd/GxkLvoEgzsnVe5VI3bo4ZHcU0lie Na1TWyNYV7E1JlC2wsFU= On Saturday 17 December 2011 16:00:03 Richard Zhao wrote: > On Fri, Dec 16, 2011 at 08:32:35AM -0600, Rob Herring wrote: > > On 12/16/2011 04:30 AM, Richard Zhao wrote: > > > It support single core and multi-core ARM SoCs. But it assume > > > all cores share the same frequency and voltage. > > > > > > Signed-off-by: Richard Zhao > > > --- > > > drivers/cpufreq/Kconfig.arm | 8 ++ > > > drivers/cpufreq/Makefile | 1 + > > > drivers/cpufreq/arm-cpufreq.c | 269 +++++++++++++++++++++++++++++++++++++++++ > > > 3 files changed, 278 insertions(+), 0 deletions(-) > > > create mode 100644 drivers/cpufreq/arm-cpufreq.c > > > > > > > What makes this specific to ARM and not a generic DT + clk api + > > regulator api driver? > > smp loops_per_jiffy update needs arm header . I would suggest to instead change the definition of adjust_jiffies in the core so it can be overridden by the architecture, like this Then ARM (and any others that want the driver) can provide their own implementation and set #define adjust_jiffies(val, ci) adjust_jiffies((val), (ci)) to let the core use that instead of the generic UP version. While we're there, we should probably try to fix drivers that use loops_per_jiffy, because that is not what they think it is on SMP. Arnd diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 987a165..174584d 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -189,6 +189,7 @@ EXPORT_SYMBOL_GPL(cpufreq_cpu_put); * systems as each CPU might be scaled differently. So, use the arch * per-CPU loops_per_jiffy value wherever possible. */ +#ifndef adjust_jiffies #ifndef CONFIG_SMP static unsigned long l_p_j_ref; static unsigned int l_p_j_ref_freq; @@ -218,7 +219,8 @@ static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci) { return; } -#endif +#endif /* CONFIG_SMP */ +#endif /* adjust_jiffies */ /**