From patchwork Thu Jun 29 10:59:05 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 106627 Delivered-To: patch@linaro.org Received: by 10.182.135.102 with SMTP id pr6csp4553911obb; Thu, 29 Jun 2017 03:59:43 -0700 (PDT) X-Received: by 10.98.80.76 with SMTP id e73mr15509880pfb.31.1498733983276; Thu, 29 Jun 2017 03:59:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498733983; cv=none; d=google.com; s=arc-20160816; b=LpXEBLaYcn+mDBxWU+NPgFXZZ/4sP60OALCg4x9aWNlXtjAAgmzS5rCWkhjZ1mHeOm f0ABsauaK94VkdlaW77xiTD6cZnnZ+EE4Wf2YqgySYoUK0rhIR3DMq5qWvChD9irCRc2 UELJLG9OzHTAIcVWSqbeVPxf8lAyMFa2XL/p/blaOY58Cjk2/7VSWF9EZgLTKq7gI2Ci rUjLGK/Q/7wHgRjW4u/sO/pTFFMZ2BHTEXsqywmYN1HUkBytBjd7jAcu+uEVKj/it5AB fb/KyR2yqBOQbYDNzXdgqkm0uEPHSHLloJ6lljWnAnOdfk3s+aM6KIJzuyYklAMeZrIs 4omg== 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=CBZ+2RltayVGxXUyPCzCrBSSZV1tBb/8GiIYVU4lWAg=; b=SYk8Gw0bsdkZSuPcPjbXxCFooba2h0SFJtbyUv544BZGVbuvs4ngY5/GBMShcZRzTV TvpgCHUbyqLBNNFautcQaSo8NEOvRpTynuRpO0hNXHYozaG52fQyAxTITMqfYxfzooha d42pXmENRQ0T4jvHb8DsHh9hRWPueJ1sSOH7q39TPhfhEtcRQ4GsyPzTIvXdbr/Gg6pB vYIbjBO1P4rpdlmP9YRe8PnfBXfxRQ8AiH8TxePUGUwJ6YqjjEGq6R6riGpEmM4cqbGe WPN9BJNLYIOzV8ZZr/U9TeIRywMpYZJF9SubXBI4CAnx/dErz6NDNPjAo2Uy+aTWMXOj Uxcw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=XK00lzh2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 h189si3453226pge.445.2017.06.29.03.59.42; Thu, 29 Jun 2017 03:59:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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=XK00lzh2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 S1752710AbdF2K7g (ORCPT + 25 others); Thu, 29 Jun 2017 06:59:36 -0400 Received: from mail-pf0-f180.google.com ([209.85.192.180]:35171 "EHLO mail-pf0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752645AbdF2K7W (ORCPT ); Thu, 29 Jun 2017 06:59:22 -0400 Received: by mail-pf0-f180.google.com with SMTP id c73so48751811pfk.2 for ; Thu, 29 Jun 2017 03:59:21 -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=CBZ+2RltayVGxXUyPCzCrBSSZV1tBb/8GiIYVU4lWAg=; b=XK00lzh22Yf3Qd568BfNtF4Wqb75xshRbPTm7OKyERIhi1OoVa13UZVtpWts322SrU hq95/S7BtSjd9uORzgdeU0QLNlb2zesUkVvPaxAafQjzMJ2su4Bnn+mLAR8FQ7ZxGkM2 UKpFFb74y1+CLcJThfozPxusHajA++8wMSAog= 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=CBZ+2RltayVGxXUyPCzCrBSSZV1tBb/8GiIYVU4lWAg=; b=CJAnlDeclqXbSX+cKRHuzc6WqCRjQrH8n5nJYl9YDOGR28aMKQTt1Cxu5+WRoCoBqD w+ggN1m1/zwYCUCqogb7iQNlNpvMZb4GIawisCXLTWCB+E8Xidb62/9oT1fCyheZT66l F2oZS+Sgr39YcySqgt/7whdmY0CkZYkKuLMLBCDx9y4ahBpg58zYPcsZn6XH7pJDE3V/ aaVWdJWRc7xXxmoHa8iLiIWR3LvmDzTT3cBPZdAS566Ugr4DxJQY8mVNcnlZqkcEjGLH egrZqKvjVDvinCPSs9ClXC0wAxzI1xYzNN223h3WWPhvCSVyqXU//DOL5h2J0/8L9kKy XA5Q== X-Gm-Message-State: AKS2vOw2jKlK6PvisgYGzMJqkvSpkySST8KM+V6Xr/fi6h0JlQAI+RfL fGs1kG8tWwUMr1eF X-Received: by 10.84.217.207 with SMTP id d15mr8135018plj.127.1498733960135; Thu, 29 Jun 2017 03:59:20 -0700 (PDT) Received: from localhost ([122.171.238.149]) by smtp.gmail.com with ESMTPSA id a29sm12006102pfg.30.2017.06.29.03.59.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 03:59:19 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki , Viresh Kumar Cc: linux-pm@vger.kernel.org, Vincent Guittot , linux-kernel@vger.kernel.org Subject: [PATCH 2/6] cpufreq: Remove (now) unused code related to max_transition_latency Date: Thu, 29 Jun 2017 16:29:05 +0530 Message-Id: <85a18d35c119cf444aeec43a828efddb2ce0e4e1.1498733506.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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Get rid of the now unused code after the only user of max_transition_latency is gone. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq.c | 5 ----- drivers/cpufreq/cpufreq_governor.h | 1 - drivers/cpufreq/cpufreq_performance.c | 6 ------ include/linux/cpufreq.h | 5 ----- 4 files changed, 17 deletions(-) -- 2.13.0.71.gd7076ec9c9cb diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 34dbbf3122c8..0508b62c6f9b 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1969,11 +1969,6 @@ int cpufreq_driver_target(struct cpufreq_policy *policy, } EXPORT_SYMBOL_GPL(cpufreq_driver_target); -__weak struct cpufreq_governor *cpufreq_fallback_governor(void) -{ - return NULL; -} - static int cpufreq_init_governor(struct cpufreq_policy *policy) { int ret; diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h index 0236ec2cd654..7cbb07512e4c 100644 --- a/drivers/cpufreq/cpufreq_governor.h +++ b/drivers/cpufreq/cpufreq_governor.h @@ -160,7 +160,6 @@ void cpufreq_dbs_governor_limits(struct cpufreq_policy *policy); #define CPUFREQ_DBS_GOVERNOR_INITIALIZER(_name_) \ { \ .name = _name_, \ - .max_transition_latency = TRANSITION_LATENCY_LIMIT, \ .owner = THIS_MODULE, \ .init = cpufreq_dbs_governor_init, \ .exit = cpufreq_dbs_governor_exit, \ diff --git a/drivers/cpufreq/cpufreq_performance.c b/drivers/cpufreq/cpufreq_performance.c index dafb679adc58..73bc6c28b956 100644 --- a/drivers/cpufreq/cpufreq_performance.c +++ b/drivers/cpufreq/cpufreq_performance.c @@ -44,12 +44,6 @@ struct cpufreq_governor *cpufreq_default_governor(void) return &cpufreq_gov_performance; } #endif -#ifndef CONFIG_CPU_FREQ_GOV_PERFORMANCE_MODULE -struct cpufreq_governor *cpufreq_fallback_governor(void) -{ - return &cpufreq_gov_performance; -} -#endif MODULE_AUTHOR("Dominik Brodowski "); MODULE_DESCRIPTION("CPUfreq policy governor 'performance'"); diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index 0818bdc3ebf2..54dfa1bdf138 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -491,7 +491,6 @@ static inline unsigned long cpufreq_scale(unsigned long old, u_int div, #define MIN_SAMPLING_RATE_RATIO (2) #define LATENCY_MULTIPLIER (1000) #define MIN_LATENCY_MULTIPLIER (20) -#define TRANSITION_LATENCY_LIMIT (10 * 1000 * 1000) struct cpufreq_governor { char name[CPUFREQ_NAME_LEN]; @@ -504,9 +503,6 @@ struct cpufreq_governor { char *buf); int (*store_setspeed) (struct cpufreq_policy *policy, unsigned int freq); - unsigned int max_transition_latency; /* HW must be able to switch to - next freq faster than this value in nano secs or we - will fallback to performance governor */ struct list_head governor_list; struct module *owner; }; @@ -526,7 +522,6 @@ int cpufreq_register_governor(struct cpufreq_governor *governor); void cpufreq_unregister_governor(struct cpufreq_governor *governor); struct cpufreq_governor *cpufreq_default_governor(void); -struct cpufreq_governor *cpufreq_fallback_governor(void); static inline void cpufreq_policy_apply_limits(struct cpufreq_policy *policy) { From patchwork Thu Jun 29 10:59:08 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 106629 Delivered-To: patch@linaro.org Received: by 10.182.135.102 with SMTP id pr6csp4554174obb; Thu, 29 Jun 2017 04:00:02 -0700 (PDT) X-Received: by 10.98.112.137 with SMTP id l131mr15983334pfc.186.1498734002845; Thu, 29 Jun 2017 04:00:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498734002; cv=none; d=google.com; s=arc-20160816; b=AwRBIysfBJnE9sAhSpEDE2mDKKoWsTW8viG5X7dmZJSBK7zaWmOZ2a0bUA1aceieqP 4biF5nAjc6s/BtJ9Y8kj0692akt1v9HuMaG4yBZWvn02bBOlon/mU/lLZkVwHLbf+Grh TyBlKJSp7lUSRwoXb2LD3+OI9XIy0lgfQmC8gksGXl+Fdudq3giTpPOftPY61HUB1N7s 2tht1IVsi2/AadYXOkMcONzO1dYWWmr4C9UXiPOGKoYfv5UApYfYfAJR9MwSwQTLC4z5 OmhM+3ekDsjQLq10u3cRcxEt5NX2ItLzcjfsBil3wuR4klNfCng1N+4dsQZw5EGTBsDR kuow== 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=mS9qEPPrc3oG+oi6FOC7EcP2IM0pU/1U4Pd0viINdzQ=; b=XdXWF4gxQVQGmL3NvM6F68MYnGzZ3DPt1SeG2XHReofO5aJYYmqEPUkwX6t5M8T39K yKrw6BycFtnFK09LvlNU+j2K7ftj9u9CPA+Wf4BQjwLqUoRlrCjG1x7tRiAnwxT63Z5S Hr7mQlwGxu7OCJqkSuWHYXOpCHIaWVCIFDb4PAlsOjMzC2YOgkpRDWZ7hwvsvgOj1dmL TWDBz5wId4yIkX2PWJlwx864J+XpIjNiCYr1djJwCXsL1wRP5zC9UDP6ccCp608XSXHB YRrgh2jlFwJyE/+7wAMmud1sO0oDp47NijgkS1LJmwKcptHNdsPvDDiG5a3keXrFkcpP sY2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=LXJJ03QX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 n1si3772598pld.585.2017.06.29.04.00.02; Thu, 29 Jun 2017 04:00:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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=LXJJ03QX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 S1752750AbdF2K77 (ORCPT + 25 others); Thu, 29 Jun 2017 06:59:59 -0400 Received: from mail-pg0-f42.google.com ([74.125.83.42]:34406 "EHLO mail-pg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752701AbdF2K7f (ORCPT ); Thu, 29 Jun 2017 06:59:35 -0400 Received: by mail-pg0-f42.google.com with SMTP id t186so46526057pgb.1 for ; Thu, 29 Jun 2017 03:59:34 -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=mS9qEPPrc3oG+oi6FOC7EcP2IM0pU/1U4Pd0viINdzQ=; b=LXJJ03QXdbytEiJUBgUN0eUocStkX+j360lsgorttFg7VTSyATPOLy7V7Tr5u7JER4 acJPo3a0d9g0p5DYCuUANSI8RwNQB87t3SKTiiNxZt37+FSq+tKnkz54AV2K+6DsDS27 b0VPIali9KnrXJ8TP7MhJAHRE919NhcwkJzDo= 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=mS9qEPPrc3oG+oi6FOC7EcP2IM0pU/1U4Pd0viINdzQ=; b=F+UKz74jqWnXIjTQkPY9V0vrrXJ3mBscebNLxo7Pm8cv+7sqO+CZaPuiV/BTxYPhfV HfO/4SPrYPJGch39VI9FPIYKh+AlW8WapzC51OBwUdG3+a6da4IxrVu91IeuPBAzwbNI AQvX0tGgYRkSiD1QOpusVvaej3THK+PWv3IE1IB0w20q1xMSq2ufhQdP3WcRSpJeiMs/ /EkElIhI/WuW96OHH4ddwD4qyvJStXbL/vAlwfuNDLWSIGBCWHTAcarAllE6LsWmdq2W vOlmdLIVDIeremfWoPGUntPG0Ogvq8uUFzg1glIY79rts7AeF7PJieGBWDiJK9rB0qew B4DQ== X-Gm-Message-State: AKS2vOyTanOiqqZPdopTJmqRx8Z3GPZo4lK9e3gW5gGNIzIMNFxMB3X3 NCTrey188BjvOI+v X-Received: by 10.99.122.18 with SMTP id v18mr15207133pgc.142.1498733969390; Thu, 29 Jun 2017 03:59:29 -0700 (PDT) Received: from localhost ([122.171.238.149]) by smtp.gmail.com with ESMTPSA id h123sm8343523pgc.36.2017.06.29.03.59.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 03:59:28 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki , Viresh Kumar Cc: linux-pm@vger.kernel.org, Vincent Guittot , linux-kernel@vger.kernel.org Subject: [PATCH 5/6] cpufreq: Cap the default transition delay value to 10 ms Date: Thu, 29 Jun 2017 16:29:08 +0530 Message-Id: <1626e6781865d68bd0e666ec941048a9a6166156.1498733506.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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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 --- include/linux/cpufreq.h | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) -- 2.13.0.71.gd7076ec9c9cb diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index dee6fe3d8af0..cf1faba29113 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -541,7 +541,17 @@ cpufreq_policy_transition_delay_us(struct cpufreq_policy *policy) if (latency) delay_us *= latency; - return delay_us; + /* + * 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(delay_us, (unsigned int)10000); } /* Governor attribute set */