From: "zhenglifeng (A)" <zhenglifeng1@huawei.com>
To: Viresh Kumar <viresh.kumar@linaro.org>,
"Rafael J. Wysocki" <rafael@kernel.org>
Cc: <linux-pm@vger.kernel.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Nicholas Chin <nic.c3.14@gmail.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] cpufreq: acpi: Don't enable boost on policy exit
Date: Wed, 16 Apr 2025 16:47:10 +0800 [thread overview]
Message-ID: <87665307-1be3-465b-ab7c-3bf908b45217@huawei.com> (raw)
In-Reply-To: <2c788c2ca0cab09a8ef4e384f272af928a880b0e.1744781329.git.viresh.kumar@linaro.org>
On 2025/4/16 13:29, Viresh Kumar wrote:
> The boost-related code in cpufreq has undergone several changes over the
> years, but this particular piece remained unchanged and is now outdated.
>
> The cpufreq core currently manages boost settings during initialization,
> and only when necessary. As such, there's no longer a need to enable
> boost explicitly when entering system suspend.
>
> Previously, this wasn’t causing issues because boost settings were
> force-updated during policy initialization. However, commit 2b16c631832d
> ("cpufreq: ACPI: Remove set_boost in acpi_cpufreq_cpu_init()") changed
> that behavior—correctly—by avoiding unnecessary updates.
>
> As a result of this change, if boost was disabled prior to suspend, it
> remains disabled on resume—as expected. But due to the current code
> forcibly enabling boost at suspend time, the system ends up with boost
> frequencies enabled after resume, even if the global boost flag was
> disabled. This contradicts the intended behavior.
>
> Fix this by not enabling boost on policy exit.
>
> Fixes: 2b16c631832d ("cpufreq: ACPI: Remove set_boost in acpi_cpufreq_cpu_init()")
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220013
> Reported-by: Nicholas Chin <nic.c3.14@gmail.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/cpufreq/acpi-cpufreq.c | 23 +++--------------------
> 1 file changed, 3 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> index 924314cdeebc..85b5a88f723f 100644
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -89,8 +89,9 @@ static bool boost_state(unsigned int cpu)
> return false;
> }
>
> -static int boost_set_msr(bool enable)
> +static void boost_set_msr_each(void *p_en)
> {
> + bool enable = (bool) p_en;
> u32 msr_addr;
> u64 msr_mask, val;
>
> @@ -107,7 +108,7 @@ static int boost_set_msr(bool enable)
> msr_mask = MSR_K7_HWCR_CPB_DIS;
> break;
> default:
> - return -EINVAL;
> + return;
> }
>
> rdmsrl(msr_addr, val);
> @@ -118,14 +119,6 @@ static int boost_set_msr(bool enable)
> val |= msr_mask;
>
> wrmsrl(msr_addr, val);
> - return 0;
> -}
> -
> -static void boost_set_msr_each(void *p_en)
> -{
> - bool enable = (bool) p_en;
> -
> - boost_set_msr(enable);
> }
>
> static int set_boost(struct cpufreq_policy *policy, int val)
> @@ -532,15 +525,6 @@ static void free_acpi_perf_data(void)
> free_percpu(acpi_perf_data);
> }
>
> -static int cpufreq_boost_down_prep(unsigned int cpu)
> -{
> - /*
> - * Clear the boost-disable bit on the CPU_DOWN path so that
> - * this cpu cannot block the remaining ones from boosting.
> - */
> - return boost_set_msr(1);
> -}
> -
> /*
> * acpi_cpufreq_early_init - initialize ACPI P-States library
> *
> @@ -931,7 +915,6 @@ static void acpi_cpufreq_cpu_exit(struct cpufreq_policy *policy)
>
> pr_debug("%s\n", __func__);
>
> - cpufreq_boost_down_prep(policy->cpu);
> policy->fast_switch_possible = false;
> policy->driver_data = NULL;
> acpi_processor_unregister_performance(data->acpi_perf_cpu);
Nice!
I wonder why this cpufreq_boost_down_prep() was needed at the beginning.
Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com>
next prev parent reply other threads:[~2025-04-16 8:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-16 5:29 Viresh Kumar
2025-04-16 8:47 ` zhenglifeng (A) [this message]
2025-04-16 12:38 ` Rafael J. Wysocki
2025-04-17 1:54 ` Nicholas Chin
2025-04-17 5:02 ` Viresh Kumar
2025-04-17 5:09 ` Viresh Kumar
2025-04-17 12:39 ` Rafael J. Wysocki
2025-04-17 15:53 ` Rafael J. Wysocki
2025-04-18 5:58 ` Viresh Kumar
2025-04-18 17:06 ` Nicholas Chin
2025-04-18 19:28 ` Rafael J. Wysocki
2025-04-19 7:54 ` Viresh Kumar
2025-04-19 9:35 ` zhenglifeng (A)
2025-04-21 6:20 ` Viresh Kumar
2025-04-21 7:45 ` zhenglifeng (A)
2025-04-21 11:37 ` Viresh Kumar
2025-04-21 13:36 ` zhenglifeng (A)
2025-04-22 9:41 ` Viresh Kumar
2025-04-22 12:05 ` zhenglifeng (A)
2025-04-17 12:36 ` 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=87665307-1be3-465b-ab7c-3bf908b45217@huawei.com \
--to=zhenglifeng1@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=nic.c3.14@gmail.com \
--cc=rafael.j.wysocki@intel.com \
--cc=rafael@kernel.org \
--cc=vincent.guittot@linaro.org \
--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
all inboxes | Powered by JetHome®