From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Linux PM <linux-pm@vger.kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Zhang Rui <rui.zhang@intel.com>
Subject: [PATCH v2 1/4] cpufreq: Introduce CPUFREQ_NEED_UPDATE_LIMITS driver flag
Date: Fri, 23 Oct 2020 17:35:19 +0200 [thread overview]
Message-ID: <1673796.UrKzctInAk@kreacher> (raw)
In-Reply-To: <2183878.gTFULuzKx9@kreacher>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Generally, a cpufreq driver may need to update some internal upper
and lower frequency boundaries on policy max and min changes,
respectively, but currently this does not work if the target
frequency does not change along with the policy limit.
Namely, if the target frequency does not change along with the
policy min or max, the "target_freq == policy->cur" check in
__cpufreq_driver_target() prevents driver callbacks from being
invoked and they do not even have a chance to update the
corresponding internal boundary.
This particularly affects the "powersave" and "performance"
governors that always set the target frequency to one of the
policy limits and it never changes when the other limit is updated.
To allow cpufreq the drivers needing to update internal frequency
boundaries on policy limits changes to avoid this issue, introduce
a new driver flag, CPUFREQ_NEED_UPDATE_LIMITS, that (when set) will
neutralize the check mentioned above.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
New patch in v2.
---
drivers/cpufreq/cpufreq.c | 3 ++-
include/linux/cpufreq.h | 10 +++++++++-
2 files changed, 11 insertions(+), 2 deletions(-)
Index: linux-pm/include/linux/cpufreq.h
===================================================================
--- linux-pm.orig/include/linux/cpufreq.h
+++ linux-pm/include/linux/cpufreq.h
@@ -297,7 +297,7 @@ __ATTR(_name, 0644, show_##_name, store_
struct cpufreq_driver {
char name[CPUFREQ_NAME_LEN];
- u8 flags;
+ u16 flags;
void *driver_data;
/* needed by all drivers */
@@ -417,6 +417,14 @@ struct cpufreq_driver {
*/
#define CPUFREQ_IS_COOLING_DEV BIT(7)
+/*
+ * Set by drivers that need to update internale upper and lower boundaries along
+ * with the target frequency and so the core and governors should also invoke
+ * the diver if the target frequency does not change, but the policy min or max
+ * may have changed.
+ */
+#define CPUFREQ_NEED_UPDATE_LIMITS BIT(8)
+
int cpufreq_register_driver(struct cpufreq_driver *driver_data);
int cpufreq_unregister_driver(struct cpufreq_driver *driver_data);
Index: linux-pm/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq.c
+++ linux-pm/drivers/cpufreq/cpufreq.c
@@ -2191,7 +2191,8 @@ int __cpufreq_driver_target(struct cpufr
* exactly same freq is called again and so we can save on few function
* calls.
*/
- if (target_freq == policy->cur)
+ if (target_freq == policy->cur &&
+ !(cpufreq_driver->flags & CPUFREQ_NEED_UPDATE_LIMITS))
return 0;
if (cpufreq_driver->target)
next prev parent reply other threads:[~2020-10-23 15:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-23 15:21 [PATCH v2 0/4] cpufreq: intel_pstate: Avoid missing HWP max limit updates with powersave governor Rafael J. Wysocki
2020-10-23 15:35 ` Rafael J. Wysocki [this message]
2020-10-27 3:06 ` [PATCH v2 1/4] cpufreq: Introduce CPUFREQ_NEED_UPDATE_LIMITS driver flag Viresh Kumar
2020-10-23 15:35 ` [PATCH v2 2/4] cpufreq: intel_pstate: Avoid missing HWP max updates in passive mode Rafael J. Wysocki
2020-10-27 3:06 ` Viresh Kumar
2020-10-27 8:47 ` Zhang Rui
2020-10-23 15:35 ` [PATCH v2 3/4] cpufreq: Introduce cpufreq_driver_test_flags() Rafael J. Wysocki
2020-10-23 15:36 ` [PATCH v2 4/4] cpufreq: schedutil: Always call drvier if need_freq_update is set Rafael J. Wysocki
2020-10-27 4:25 ` Viresh Kumar
2020-10-27 13:14 ` Rafael J. Wysocki
2020-10-27 8:47 ` Zhang Rui
2020-10-27 15:35 ` [PATCH v2.1 4/4] cpufreq: schedutil: Always call driver " Rafael J. Wysocki
2020-10-28 3:57 ` Viresh Kumar
2020-10-29 10:42 ` Rafael J. Wysocki
2020-10-29 10:54 ` Viresh Kumar
2020-10-29 11:12 ` [PATCH v2.2 4/4] cpufreq: schedutil: Always call driver if CPUFREQ_NEED_UPDATE_LIMITS " Rafael J. Wysocki
2020-10-29 11:23 ` Viresh Kumar
2020-10-29 11:29 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1673796.UrKzctInAk@kreacher \
--to=rjw@rjwysocki.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rui.zhang@intel.com \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).