From: Shawn Guo <shawnguo2@yeah.net>
To: Qais Yousef <qyousef@layalina.io>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
Shawn Guo <shawnguo@kernel.org>,
stable@vger.kernel.org
Subject: Re: [PATCH] cpufreq: cap the default transition delay at 10 ms
Date: Mon, 15 Sep 2025 15:29:05 +0800 [thread overview]
Message-ID: <aMfAQXE4sRjru9I_@dragon> (raw)
In-Reply-To: <20250914174326.i7nqmrzjtjq7kpqm@airbuntu>
On Sun, Sep 14, 2025 at 06:43:26PM +0100, Qais Yousef wrote:
> > > Why do you want to address the issue in the cpufreq core instead of
> > > doing that in the cpufreq-dt driver?
> >
> > My intuition was to fix the regression at where the regression was
> > introduced by recovering the code behavior.
>
> Isn't the right fix here is at the driver level still? We can only give drivers
> what they ask for. If they ask for something wrong and result in something
> wrong, it is still their fault, no?
I'm not sure. The cpufreq-dt driver is following suggestion to use
CPUFREQ_ETERNAL, which has the implication that core will figure out
a reasonable default value for platforms where the latency is unknown.
And that was exactly the situation before the regression. How does it
become the fault of cpufreq-dt driver?
> Alternatively maybe we can add special handling for CPUFREQ_ETERNAL value,
> though I'd suggest to return 1ms (similar to the case of value being 0). Maybe
> we can redefine CPUFREQ_ETERNAL to be 0, but not sure if this can have side
> effects.
Changing CPUFREQ_ETERNAL to 0 looks so risky to me. What about adding
an explicit check for CPUFREQ_ETERNAL?
---8<---
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index fc7eace8b65b..053f3a0288bc 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -549,11 +549,15 @@ unsigned int cpufreq_policy_transition_delay_us(struct cpufreq_policy *policy)
if (policy->transition_delay_us)
return policy->transition_delay_us;
+ if (policy->cpuinfo.transition_latency == CPUFREQ_ETERNAL)
+ goto default_delay;
+
latency = policy->cpuinfo.transition_latency / NSEC_PER_USEC;
if (latency)
/* Give a 50% breathing room between updates */
return latency + (latency >> 1);
+default_delay:
return USEC_PER_MSEC;
}
EXPORT_SYMBOL_GPL(cpufreq_policy_transition_delay_us);
--->8---
Shawn
next prev parent reply other threads:[~2025-09-15 7:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 6:53 [PATCH] cpufreq: cap the default transition delay at 10 ms Shawn Guo
2025-09-10 7:11 ` Shawn Guo
2025-09-12 10:41 ` Rafael J. Wysocki
2025-09-12 13:07 ` Shawn Guo
2025-09-14 17:43 ` Qais Yousef
2025-09-15 7:29 ` Shawn Guo [this message]
2025-09-15 10:02 ` Qais Yousef
2025-09-15 12:20 ` Shawn Guo
2025-09-15 13:18 ` Rafael J. Wysocki
2025-09-16 1:52 ` Shawn Guo
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=aMfAQXE4sRjru9I_@dragon \
--to=shawnguo2@yeah.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=qyousef@layalina.io \
--cc=rafael@kernel.org \
--cc=shawnguo@kernel.org \
--cc=stable@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.