From patchwork Thu Jun 29 10:59:04 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 106626 Delivered-To: patch@linaro.org Received: by 10.182.135.102 with SMTP id pr6csp4553543obb; Thu, 29 Jun 2017 03:59:20 -0700 (PDT) X-Received: by 10.98.86.3 with SMTP id k3mr10071158pfb.144.1498733960003; Thu, 29 Jun 2017 03:59:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498733959; cv=none; d=google.com; s=arc-20160816; b=ZXIS2cu57NEEB5zfEHZpKfJH1dQRnY0WMHYuexCRCCI02sIZif3qgmnrkhcI4ASFVr PQ3V8BogRbzp1OfNltRfn16z5PkOx7/R/cWrqOFpgiRdIEeNy9oYpJWMkeO1NbWIZ7D5 eaaaGs4epzTwg9oggRbg2wf+8ZmTEZB4VlCNWHXlDvz/q52lLcb7zpFmbdgYB0HE8Q/T Sy8ivvzOWHtlfVIGqKkRyzpf9zZ2mhx8ZqsBQry8orO/7EeO8Y3MVeCevL/Cgdd6g4YH rMdalCqPFDquy3XZjYC62yJLTe+xdjnSautVlWcyJ3jfMRxABvqrCl5cE5FESbEpkeNK V9zg== 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=Al/xZgSM6SZzr6Mzr2dz6GxkNO9nE0hAkMWS5HXPbCE=; b=jBdM4U3srnR3BkgPBrRIiYqgiS+05f5DNk/cDhfMhFH9a8U07qxi2aZWU/EU2AMRaU dHZutIPP8NTh+Q/22UswzJ/8ZDVfodi/IW/m+O0znnS0RWOCQ5Xkv6Ar5uXuLfhuWNg7 lhpR3VpDIPHGjGlGMoHg64W62n6HmiyhUhNeT2cHtwX1Mx2ejAcKZHimZrFPZR79TXeE bOoAaWYyXNokluL78djVA6S0Eqc9WLXynGlW03zcCwcLqe7Wc1vl8/75OsqNsriVljZS 7dPizXH3tDvVcg4GQw6CRXObbHK3heAUWSIgrmM+dEiYVedcJVK//9vo8YYfeGYry+I8 nFJg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=X4eehn1F; 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 d6si3888652plj.558.2017.06.29.03.59.19; Thu, 29 Jun 2017 03:59:19 -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=X4eehn1F; 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 S1752626AbdF2K7S (ORCPT + 14 others); Thu, 29 Jun 2017 06:59:18 -0400 Received: from mail-pg0-f50.google.com ([74.125.83.50]:36143 "EHLO mail-pg0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752440AbdF2K7R (ORCPT ); Thu, 29 Jun 2017 06:59:17 -0400 Received: by mail-pg0-f50.google.com with SMTP id u62so46261953pgb.3 for ; Thu, 29 Jun 2017 03:59:17 -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=Al/xZgSM6SZzr6Mzr2dz6GxkNO9nE0hAkMWS5HXPbCE=; b=X4eehn1FtiFsVSnLFQQyPAwFykDx0CtiPVcPywUnJJO0DXWnIPlNq07ANnvKLLB4hw McQ0GE6ihp9KdSwumQ4IVZtXrwgnOC9y1BEW6txpLxgH37rTj89qQyreU9unmQcZY4F8 KfPfiCZNrV0UQyZlYwPOBLjZMUF2rNqO7pt68= 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=Al/xZgSM6SZzr6Mzr2dz6GxkNO9nE0hAkMWS5HXPbCE=; b=LUDWDDJwc3bRBqxrwSpVLZN88CVyNHF0twaTMlpVx7lQX6Gvt0HckNnoZHlxpNEzCr wfvajouwdQ+epqPdc3qfioxBCXvrx4qEYO2hP28h/Ou5wpumXShTv8xJH4s81E7WgkZy iEU6ewVeTXzAn8hma5QXtE2Z02yoJj2J5AGJETkrXR2Yi7ncqhlF9dnqabWw2WVY/mI7 d3Xlb8Vzx6Bqr1wU5GWcjfw+hEuvrj3BZOvOue3E0b3T7aM6fjN0o0b1GXfC2UB+XGA4 n7wjC3ykSVgiHbYUCswuHoddjK9XmOzBMSFcmw12QYx43Qm4nkOpQH0+Wnnov4vIOkp6 97LQ== X-Gm-Message-State: AKS2vOyyFueiy2Jvc9UGWFbkSKraBd531fjPetbbo24DiY0KBBwNcN6e sH8C0VdWORpvM+GNo2NK1g== X-Received: by 10.99.115.2 with SMTP id o2mr15315769pgc.48.1498733957150; Thu, 29 Jun 2017 03:59:17 -0700 (PDT) Received: from localhost ([122.171.238.149]) by smtp.gmail.com with ESMTPSA id t26sm4231118pfl.41.2017.06.29.03.59.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 03:59:16 -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 1/6] cpufreq: Don't check for max_transition_latency Date: Thu, 29 Jun 2017 16:29:04 +0530 Message-Id: <9924a30ffcce1b83fd6b3d199753a039a1d6f5ef.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-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org This check is there only for drivers that set transition_latency to CPUFREQ_ETERNAL. And the "max_transition_latency" field is only set for ondemand and conservative governors (i.e. This code doesn't run for schedutil governor). With CPUFREQ_ETERNAL, transition latency becomes around 4 seconds (yeah its practically impossible). But even then there is nothing particular in the governor's code that will not function if the latency is over 10ms (TRANSITION_LATENCY_LIMIT). Why disable use of the governor completely ? And if its about falling back to the performance governor for such platforms, then we aren't doing the same for schedutil governor. This patch get rids of this particular check and let platforms decide if they want to use legacy governors or not. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq.c | 14 -------------- include/linux/cpufreq.h | 3 --- 2 files changed, 17 deletions(-) -- 2.13.0.71.gd7076ec9c9cb diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 6e7424d12de9..34dbbf3122c8 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1988,20 +1988,6 @@ static int cpufreq_init_governor(struct cpufreq_policy *policy) if (!policy->governor) return -EINVAL; - if (policy->governor->max_transition_latency && - policy->cpuinfo.transition_latency > - policy->governor->max_transition_latency) { - struct cpufreq_governor *gov = cpufreq_fallback_governor(); - - if (gov) { - pr_warn("%s governor failed, too long transition latency of HW, fallback to %s governor\n", - policy->governor->name, gov->name); - policy->governor = gov; - } else { - return -EINVAL; - } - } - if (!try_module_get(policy->governor->owner)) return -EINVAL; diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index 905117bd5012..0818bdc3ebf2 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -487,9 +487,6 @@ static inline unsigned long cpufreq_scale(unsigned long old, u_int div, * polling frequency is 1000 times the transition latency of the processor. The * ondemand governor will work on any processor with transition latency <= 10ms, * using appropriate sampling rate. - * - * For CPUs with transition latency > 10ms (mostly drivers with CPUFREQ_ETERNAL) - * the ondemand governor will not work. All times here are in us (microseconds). */ #define MIN_SAMPLING_RATE_RATIO (2) #define LATENCY_MULTIPLIER (1000)