[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250117101457.1530653-2-zhenglifeng1@huawei.com>
Date: Fri, 17 Jan 2025 18:14:54 +0800
From: Lifeng Zheng <zhenglifeng1@...wei.com>
To: <rafael@...nel.org>, <viresh.kumar@...aro.org>
CC: <linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linuxarm@...wei.com>, <jonathan.cameron@...wei.com>,
<zhanjie9@...ilicon.com>, <lihuisong@...wei.com>, <zhenglifeng1@...wei.com>,
<fanghao11@...wei.com>
Subject: [PATCH v2 1/4] cpufreq: Fix re-boost issue after hotplugging a cpu
It turns out that cpuX will stay on the base frequency after performing
these operations:
1. boost all cpus: echo 1 > /sys/devices/system/cpu/cpufreq/boost
2. offline the cpu: echo 0 > /sys/devices/system/cpu/cpuX/online
3. deboost all cpus: echo 0 > /sys/devices/system/cpu/cpufreq/boost
4. online the cpu: echo 1 > /sys/devices/system/cpu/cpuX/online
5. boost all cpus again: echo 1 > /sys/devices/system/cpu/cpufreq/boost
This is because max_freq_req of the policy is not updated during the online
process, and the value of max_freq_req before the last offline is retained.
When the CPU is boosted again, freq_qos_update_request() will do nothing
because the old value is the same as the new one. This causes the CPU stay
on the base frequency. Update max_freq_req in cpufreq_online() will solve
this problem.
Signed-off-by: Lifeng Zheng <zhenglifeng1@...wei.com>
---
drivers/cpufreq/cpufreq.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 1a4cae54a01b..5882d7f5e3c1 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1475,6 +1475,10 @@ static int cpufreq_online(unsigned int cpu)
blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
CPUFREQ_CREATE_POLICY, policy);
+ } else {
+ ret = freq_qos_update_request(policy->max_freq_req, policy->max);
+ if (ret < 0)
+ goto out_destroy_policy;
}
if (cpufreq_driver->get && has_target()) {
--
2.33.0
Powered by blists - more mailing lists