Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1368565ybk; Thu, 14 May 2020 07:20:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwJM5m1arEcc2rbuVqf3b/GZK4oDNDoUGVB3DVSaN3n5yFT/RYuPkRoaU3FXrE9WpypkSFP X-Received: by 2002:a50:c3c2:: with SMTP id i2mr4348348edf.227.1589466050039; Thu, 14 May 2020 07:20:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589466050; cv=none; d=google.com; s=arc-20160816; b=mIJo6SaXksa9LS25R1rJ0BWjbHcciUWUHBZdlFQFk4BfVvhp1osL0zI4TWnBvFdqjf tkvuGHafKNhyvXVYut7BHCweBbfFMFaRsfbLMLNCF1yoGpupTnL3e8VrsU2Y7E6bXtlI 7xZQQabIXG11S1XM4+cQYZhEUYTXGZHvc0HUyDOM/OIOQnSfAMo0mBpN7bdpkHgbfPOK Z5YIAi+Z0Nf3XrTFNnbdWNqX8unr8yFkO33nb6IloBwowMR+7ckDyDfz2PBxKTNeGZBU rWtK6re4B2CfKf36KaFRrm9su7RHts5Z1y29eyYliXELJVeDoduaqNVTzmfJE2SG0Mmd Q9kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=B13ug0mrh4OqL9jmsLr/FNS69VvuhBFW9xAVEYzpk0M=; b=uAy6W3bg7Pe1b/HJONikmzh0NduBQKnGTRL4xKXsZM+Bwab3brKzBVQoGSQvnlgxAi y2bitdoGSlTi/jDP4dvu2dukfgKkC7V9IjIIPBPsRFlUTfmDFY9QP1IY3zF6aCHFGO49 k9HG7RNM19vl6y+zQBDBfGsqWd3BKylYLO2si+o/FBINS2fUzHfMzryOzKdrTHfHn3w0 +RVAvgpy8oqgpqrQt8KNIeOXQGNEZ6tN7tDXqJSfVBbYwhDKT44Mc/qUDIzh5KvLqAEF i1ooE7uCLnH/2uf5prpeTxf4123b65ae6qHrXUUDeYzIy5tMzcqnvmeTNfqtpZ97JLE2 7i6g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id oz11si1933653ejb.151.2020.05.14.07.20.26; Thu, 14 May 2020 07:20:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726763AbgENOQd (ORCPT + 99 others); Thu, 14 May 2020 10:16:33 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:48348 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726050AbgENOQd (ORCPT ); Thu, 14 May 2020 10:16:33 -0400 Received: from 89-64-84-17.dynamic.chello.pl (89.64.84.17) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.415) id ce086dfbd8228c14; Thu, 14 May 2020 16:16:30 +0200 From: "Rafael J. Wysocki" To: Xiongfeng Wang Cc: viresh.kumar@linaro.org, Souvik.Chakravarty@arm.com, Thanu.Rangarajan@arm.com, Sudeep.Holla@arm.com, guohanjun@huawei.com, john.garry@huawei.com, jonathan.cameron@huawei.com, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 2/3] cpufreq: Add SW BOOST support for drivers without frequency table Date: Thu, 14 May 2020 16:16:29 +0200 Message-ID: <5858421.kfVlu25t0p@kreacher> In-Reply-To: <1588929064-30270-3-git-send-email-wangxiongfeng2@huawei.com> References: <1588929064-30270-1-git-send-email-wangxiongfeng2@huawei.com> <1588929064-30270-3-git-send-email-wangxiongfeng2@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday, May 8, 2020 11:11:03 AM CEST Xiongfeng Wang wrote: > Software-managed BOOST get the boost frequency by check the flag > CPUFREQ_BOOST_FREQ at driver's frequency table. But some cpufreq driver > don't have frequency table and use other methods to get the frequency > range, such CPPC cpufreq driver. > > To add SW BOOST support for drivers without frequency table, we add > members in 'cpufreq_policy.cpufreq_cpuinfo' to record the max frequency > of boost mode and non-boost mode. The cpufreq driver initialize these two > members when probing. > > Signed-off-by: Xiongfeng Wang > --- > drivers/cpufreq/cpufreq.c | 23 +++++++++++++++-------- > include/linux/cpufreq.h | 2 ++ > 2 files changed, 17 insertions(+), 8 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index 475fb1b..a299426 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -2508,15 +2508,22 @@ static int cpufreq_boost_set_sw(int state) > int ret = -EINVAL; > > for_each_active_policy(policy) { > - if (!policy->freq_table) > - continue; > - > - ret = cpufreq_frequency_table_cpuinfo(policy, > + if (policy->freq_table) { > + ret = cpufreq_frequency_table_cpuinfo(policy, > policy->freq_table); > - if (ret) { > - pr_err("%s: Policy frequency update failed\n", > - __func__); > - break; > + if (ret) { > + pr_err("%s: Policy frequency update failed\n", > + __func__); > + break; > + } > + } else if (policy->cpuinfo.boost_max_freq) { > + if (state) > + policy->max = policy->cpuinfo.boost_max_freq; > + else > + policy->max = policy->cpuinfo.nonboost_max_freq; > + policy->cpuinfo.max_freq = policy->max; > + } else { > + continue; > } Why do you need to update this function? The driver should be able to provide its own ->set_boost callback just fine, shouldn't it? > > ret = freq_qos_update_request(policy->max_freq_req, policy->max); > diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h > index 018dce8..c3449e6 100644 > --- a/include/linux/cpufreq.h > +++ b/include/linux/cpufreq.h > @@ -43,6 +43,8 @@ enum cpufreq_table_sorting { > struct cpufreq_cpuinfo { > unsigned int max_freq; > unsigned int min_freq; > + unsigned int boost_max_freq; > + unsigned int nonboost_max_freq; > > /* in 10^(-9) s = nanoseconds */ > unsigned int transition_latency; >