From patchwork Fri Nov 22 07:03:32 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 21675 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-qe0-f71.google.com (mail-qe0-f71.google.com [209.85.128.71]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id D5A4E2096D for ; Fri, 22 Nov 2013 07:03:42 +0000 (UTC) Received: by mail-qe0-f71.google.com with SMTP id 1sf1697764qec.2 for ; Thu, 21 Nov 2013 23:03:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-unsubscribe:content-type :content-transfer-encoding; bh=DxGYGgP32bYeyD9uWvQL/xU92plwEf4QKt69Y0W2Zxo=; b=Ey1Sf9doDAEKSqAbORC/HRPNG1TtPMj71eXd6Z+ttEpohjgo7mXEIMUkFDwgozd9u1 HD/HvjED0XgqHjFShkQQlXfih2NZeGnMZUwW8Mg4MUEv6KPQIrwFT7umkFsxOz6KT1/m Ps/igazEqFcUZlNzHDHJrJ9y9RYsiaIrneG0A5gtXY1TwZSeQ2B+qIf2NLA28D8Heexi cORsQx1KWMX0U2LZOCt5CPKyyQgNFcRHeun+83m8Am7MX3Qe1Egy/mr0whB6oQmChApX HnGBWDB3OIQP0NB6sXy0ol1uVSnGkFXCw1c5mqSRidQP9ggw6j2VAFth2nhHvo+Wtene cy5w== X-Gm-Message-State: ALoCoQmSrgrBpF3kbTxFHhxAMruhmA+JI8yPpnL9wKmj5d4z+q7jgvLA9EWM0PKHWjogre/6Ism1 X-Received: by 10.59.5.7 with SMTP id ci7mr3360155ved.11.1385103821453; Thu, 21 Nov 2013 23:03:41 -0800 (PST) X-BeenThere: patchwork-forward@linaro.org Received: by 10.49.121.170 with SMTP id ll10ls887510qeb.34.gmail; Thu, 21 Nov 2013 23:03:41 -0800 (PST) X-Received: by 10.52.177.166 with SMTP id cr6mr8318663vdc.26.1385103821346; Thu, 21 Nov 2013 23:03:41 -0800 (PST) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by mx.google.com with ESMTPS id g9si12153405vcu.86.2013.11.21.23.03.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 23:03:41 -0800 (PST) Received-SPF: neutral (google.com: 209.85.128.172 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) client-ip=209.85.128.172; Received: by mail-ve0-f172.google.com with SMTP id jw12so616502veb.31 for ; Thu, 21 Nov 2013 23:03:41 -0800 (PST) X-Received: by 10.58.143.17 with SMTP id sa17mr10078252veb.14.1385103821227; Thu, 21 Nov 2013 23:03:41 -0800 (PST) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patches@linaro.org Received: by 10.220.174.196 with SMTP id u4csp19752vcz; Thu, 21 Nov 2013 23:03:40 -0800 (PST) X-Received: by 10.224.34.71 with SMTP id k7mr18594739qad.15.1385103820007; Thu, 21 Nov 2013 23:03:40 -0800 (PST) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by mx.google.com with ESMTPS id j3si22068091qab.27.2013.11.21.23.03.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 23:03:39 -0800 (PST) Received-SPF: neutral (google.com: 209.85.216.178 is neither permitted nor denied by best guess record for domain of viresh.kumar@linaro.org) client-ip=209.85.216.178; Received: by mail-qc0-f178.google.com with SMTP id i17so320005qcy.23 for ; Thu, 21 Nov 2013 23:03:39 -0800 (PST) X-Received: by 10.224.98.200 with SMTP id r8mr18961975qan.26.1385103819742; Thu, 21 Nov 2013 23:03:39 -0800 (PST) Received: from [127.0.0.1] (git.linaro.org. [54.235.93.228]) by mx.google.com with ESMTPSA id p20sm33726408qay.0.2013.11.21.23.03.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 23:03:39 -0800 (PST) Message-ID: <528F01C4.1050608@linaro.org> Date: Fri, 22 Nov 2013 12:33:32 +0530 From: viresh kumar User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: nm@ti.com CC: rjw@rjwysocki.net, linaro-kernel@lists.linaro.org, patches@linaro.org, cpufreq@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, shawn.guo@linaro.org, ceh@ti.com, Viresh Kumar Subject: Re: [PATCH] cpufreq: Make sure CPU is running on a freq from freq-table References: In-Reply-To: X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: viresh.kumar@linaro.org X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.128.172 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Precedence: list Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org List-ID: X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , On Thursday 21 November 2013 12:39 PM, Viresh Kumar wrote: > Sometimes boot loaders set CPU frequency to a value outside of frequency table > present with cpufreq core. In such cases CPU might be unstable if it has to run > on that frequency for long duration of time and so its better to set it to a > frequency which is specified in freq-table. This also makes cpufreq stats > inconsistent as cpufreq-stats would fail to register because current frequency > of CPU isn't found in freq-table. > > Because we don't want this change to effect boot process badly, we go for the > next freq which is >= policy->cur ('cur' must be set by now, otherwise we will > end up setting freq to lowest of the table as 'cur' is initialized to zero). > > In case where CPU is already running on one of the frequencies present in > freq-table, this would turn into a dummy call as __cpufreq_driver_target() would > return early. > > Reported-by: Carlos Hernandez > Reported-by: Nishanth Menon > Signed-off-by: Viresh Kumar Copying another mail from Nishant here to get my cc'list back.. On Friday 22 November 2013 05:12 AM, Nishanth Menon wrote: > I gave this a quick run on my 3.12 kernel: > http://pastebin.mozilla.org/3649730 is what I applied and output > http://pastebin.mozilla.org/3649729 > > I need to see what I might have mucked up.. or see if I can test this > on 3.13 master on a different board (since OMAP5 wont boot in master > without clock dts nodes :().. This happened because of common sense, which was missing in my patch :) Try this over existing patch: /* related cpus should atleast have policy->cpus */ diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 6e8b226..e403388 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1126,13 +1126,19 @@ static int __cpufreq_add_dev(struct device *dev, struct subsys_interface *sif, * In case where CPU is already running on one of the frequencies * present in freq-table, this would turn into a dummy call as * __cpufreq_driver_target() would return early. + * + * We are passing target-freq as "policy->cur - 1" otherwise + * __cpufreq_driver_target() would simply fail, as policy->cur will be + * equal to target-freq. */ if (has_target()) { - ret = __cpufreq_driver_target(policy, policy->cur, + ret = __cpufreq_driver_target(policy, policy->cur - 1, CPUFREQ_RELATION_L); - if (ret) + if (ret) { pr_err("%s: Unable to set frequency from table: %d\n", __func__, ret); + goto err_out_unregister; + } }