From patchwork Tue Jun 7 02:05:29 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nishanth Menon X-Patchwork-Id: 855072 X-Patchwork-Delegate: khilman@deeprootsystems.com Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter1.kernel.org (8.14.4/8.14.3) with ESMTP id p5725lY6020074 for ; Tue, 7 Jun 2011 02:05:55 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756905Ab1FGCFo (ORCPT ); Mon, 6 Jun 2011 22:05:44 -0400 Received: from na3sys009aog104.obsmtp.com ([74.125.149.73]:49566 "EHLO na3sys009aog104.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754406Ab1FGCFo (ORCPT ); Mon, 6 Jun 2011 22:05:44 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTe2Hd0YIo2n5ILTUPw7CZTHsAIzwIMMX@postini.com; Mon, 06 Jun 2011 19:05:43 PDT Received: by yia27 with SMTP id 27so813865yia.32 for ; Mon, 06 Jun 2011 19:05:42 -0700 (PDT) Received: by 10.236.28.201 with SMTP id g49mr6621360yha.462.1307412337280; Mon, 06 Jun 2011 19:05:37 -0700 (PDT) Received: from localhost (dragon.ti.com [192.94.94.33]) by mx.google.com with ESMTPS id c63sm2984560yhe.18.2011.06.06.19.05.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2011 19:05:36 -0700 (PDT) From: Nishanth Menon To: linux-omap Cc: kevin , Colin Cross Subject: [pm-wip/cpufreq][PATCH 2/3] OMAP2+: cpufreq: notify even with bad boot frequency Date: Mon, 6 Jun 2011 21:05:29 -0500 Message-Id: <1307412330-25798-3-git-send-email-nm@ti.com> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1307412330-25798-1-git-send-email-nm@ti.com> References: <1307412330-25798-1-git-send-email-nm@ti.com> Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter1.kernel.org [140.211.167.41]); Tue, 07 Jun 2011 02:05:55 +0000 (UTC) From: Colin Cross Sometimes, bootloaders starts up with a frequency which is not in the OPP table. At cpu_init, policy->cur contains the frequency we pick at boot. It is possible that system might have fixed it's boot frequency later on as part of power initialization. After this condition, the first call to omap_target results in the following: omap_getspeed(actual device frequency) != policy->cur(frequency that cpufreq thinks that the system is at), and it is possible that freqs.old == freqs.new (because the governor requested a scale down). We exit without triggering the notifiers in the current code, which does'nt let code which depends on cpufreq_notify_transition to have accurate information as to what the system frequency is. Instead, we do a normal transition if policy->cur is wrong, then, freqs.old will be the actual cpu frequency, freqs.new will be the actual new cpu frequency and all required notifiers have the accurate information. Acked-by: Nishanth Menon Signed-off-by: Colin Cross --- arch/arm/mach-omap2/omap2plus-cpufreq.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c b/arch/arm/mach-omap2/omap2plus-cpufreq.c index a962a31..2177381 100644 --- a/arch/arm/mach-omap2/omap2plus-cpufreq.c +++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c @@ -97,7 +97,7 @@ static int omap_target(struct cpufreq_policy *policy, freqs.old = omap_getspeed(policy->cpu); freqs.cpu = policy->cpu; - if (freqs.old == freqs.new) + if (freqs.old == freqs.new && policy->cur == freqs.new) return ret; if (!is_smp()) {