From patchwork Wed Jul 19 10:12:43 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 108266 Delivered-To: patch@linaro.org Received: by 10.182.45.195 with SMTP id p3csp666184obm; Wed, 19 Jul 2017 03:15:05 -0700 (PDT) X-Received: by 10.84.216.6 with SMTP id m6mr2366251pli.299.1500459305491; Wed, 19 Jul 2017 03:15:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1500459305; cv=none; d=google.com; s=arc-20160816; b=ALLWuKCiT6RgPm988yKHHvSpinqf1DCdnB5wAEU/YQmJZybqkRtSrMe42hqHdg9ebU MA9iaQYwgN4QTk+0kAEa3rn5+bKOVq4dN8mQofOifr1mgScBoS03KY0GDIbikg6qoJ7B Jpquvr+Y8glttg6q2QDQjqGFveSjtv/C2eE26lCeUPbGIjDACyOoPSTAkwQtQPOQ1jLY hMSZmblhmlubwLtbFidll1siei8ibjgqaCHBM4kVitgNc/emOoo3jD2+6K+pWsqECvpN 4zrg1MbLpxTV9ZDm/oS6PLXpVBJX5/DYDeCSumNCEBGc/P1dYUQSpK6f6df2X48C/V34 0G7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=xYHREeIHpKkzE7W2355ZPaRIpSZ9agrHodJK4ed6LI0=; b=Jpo+6eyJxgJiam/BUxeOaY8YazNaZvg9W8BZBcbt0cyPBTqZ40dd8WspATn3MWhNx1 jv6QAcs+x1Ih4nhU8YRQzdsDUl8I2ayiOsNf/Rtoml9oTh8BdQmOY8So8EOsqDLT3X13 PZAMlkXwNkcmyjUYsWVve9ModhuLdp0YCyJEAZd5b3djg38n6l95K1Re0JKB/SSbTIkK EGdBz6Hgm8r3j2UwlNg6Vh7InPiRcS9mpIXRFtok2Zh9RhDhdwgC5RBn2JK6VfKVx6ml zny1g3Z2gDdKA5vJgMibLBizRCNa67cFO9rbGsUOys74yeNqKaXdMcrfefHe8QVrV35N fr0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=FOEEsiZd; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1si2487200pln.153.2017.07.19.03.15.05; Wed, 19 Jul 2017 03:15:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.b=FOEEsiZd; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754513AbdGSKPC (ORCPT + 13 others); Wed, 19 Jul 2017 06:15:02 -0400 Received: from mail-pf0-f170.google.com ([209.85.192.170]:33585 "EHLO mail-pf0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754078AbdGSKNV (ORCPT ); Wed, 19 Jul 2017 06:13:21 -0400 Received: by mail-pf0-f170.google.com with SMTP id s70so16176198pfs.0 for ; Wed, 19 Jul 2017 03:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :in-reply-to:references; bh=xYHREeIHpKkzE7W2355ZPaRIpSZ9agrHodJK4ed6LI0=; b=FOEEsiZdQkPY5IfOgBshmjc/YN0GzMh8s7T9U59h6rQSd+ofhVafbRQrBcesi6jVrZ CTBNN3JdPLvRsBzeh2YjGGpskTxR2drAwxO6CgLfnWfZWwmSaSaVfMeIt6LUthUYlIvT iFNdFcKdocW3YMbIR6DlZfhHsICp23D6qcyS4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:in-reply-to:references; bh=xYHREeIHpKkzE7W2355ZPaRIpSZ9agrHodJK4ed6LI0=; b=A+IMKB5x5vs3AZWtOM7MGFDgACxEfkaQg8USDLMBs7n2aOE0pAesdX2WA3AAhn2PQh 6PWFOgxXsUvKx4AGF4R+4OYubUmL3SOIQWyzdALQNi93Gr3a1il4WAwu6SVC7pyF1cf0 ACHwzU7ep1ybRB3LGfxnKLQYWO9B+eWiDZD1G8l9MQ1GTwBq2CsPsiQ79oTLhyDqQfrI moutIgLijbPS5AVgDN90Xt0ZgjdJ2TNFnmgNVyqsvyCVZVphSqFCu71q8GOvudER2Udb 7Q5/z0NjKC+N91brtq3ryCpwhX0O/QwF0ovZymnpXe8i64AApHNqnmlJ/OqRHqAC+snr +1Xg== X-Gm-Message-State: AIVw112HcgylF9qLXFaz5T9FPknWVXGdb1eKGokXJi6Y3JM2Rk/3S6SM KTK+hW6OxlW8cgii X-Received: by 10.84.206.37 with SMTP id f34mr2390146ple.262.1500459200473; Wed, 19 Jul 2017 03:13:20 -0700 (PDT) Received: from localhost ([122.167.171.93]) by smtp.gmail.com with ESMTPSA id 85sm12431594pfr.90.2017.07.19.03.13.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 03:13:19 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki , Viresh Kumar Cc: linux-pm@vger.kernel.org, Vincent Guittot , linux@dominikbrodowski.net, linux-kernel@vger.kernel.org Subject: [PATCH V3 3/9] cpufreq: Cap the default transition delay value to 10 ms Date: Wed, 19 Jul 2017 15:42:43 +0530 Message-Id: <1b93c94cb8b4914314e4f50304c3cb11c53d8b14.1500373914.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.13.0.71.gd7076ec9c9cb In-Reply-To: References: In-Reply-To: References: Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org If transition_delay_us isn't defined by the cpufreq driver, the default value of transition delay (time after which the cpufreq governor will try updating the frequency again) is currently calculated by multiplying transition_latency (nsec) with LATENCY_MULTIPLIER (1000) and then converting this time to usec. That gives the exact same value as transition_latency, just that the time unit is usec instead of nsec. With acpi-cpufreq for example, transition_latency is set to around 10 usec and we get transition delay as 10 ms. Which seems to be a reasonable amount of time to reevaluate the frequency again. But for platforms where frequency switching isn't that fast (like ARM), the transition_latency varies from 500 usec to 3 ms, and the transition delay becomes 500 ms to 3 seconds. Of course, that is a pretty bad default value to start with. We can try to come across a better formula (instead of multiplying with LATENCY_MULTIPLIER) to solve this problem, but will that be worth it ? This patch tries a simple approach and caps the maximum value of default transition delay to 10 ms. Of course, userspace can still come in and change this value anytime or individual drivers can rather provide transition_delay_us instead. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) -- 2.13.0.71.gd7076ec9c9cb Signed-off-by: Viresh Kumar diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index c426d21822f7..d00cde871c15 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -532,8 +532,19 @@ unsigned int cpufreq_policy_transition_delay_us(struct cpufreq_policy *policy) return policy->transition_delay_us; latency = policy->cpuinfo.transition_latency / NSEC_PER_USEC; - if (latency) - return latency * LATENCY_MULTIPLIER; + if (latency) { + /* + * For platforms that can change the frequency very fast (< 10 + * us), the above formula gives a decent transition delay. But + * for platforms where transition_latency is in milliseconds, it + * ends up giving unrealistic values. + * + * Cap the default transition delay to 10 ms, which seems to be + * a reasonable amount of time after which we should reevaluate + * the frequency. + */ + return min(latency * LATENCY_MULTIPLIER, (unsigned int)10000); + } return LATENCY_MULTIPLIER; }