| Message ID | 20240227233452.405852-1-qyousef@layalina.io (mailing list archive) |
|---|---|
| State | Mainlined, archived |
| Headers | show |
| Series | cpufreq: Honour transition_latency over transition_delay_us | expand |
On Wed, Feb 28, 2024 at 12:35 AM Qais Yousef <qyousef@layalina.io> wrote: > > Some platforms like Arm's Juno can have a high transition latency that > can be larger than the 2ms cap introduced. If a driver report > a transition_latency that is higher than the cap, then use it as-is. > > Update comment s/10/2/ to reflect the new cap of 2ms. > > Reported-by: Pierre Gondois <pierre.gondois@arm.com> > Signed-off-by: Qais Yousef <qyousef@layalina.io> > --- > drivers/cpufreq/cpufreq.c | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index 66cef33c4ec7..926a51cb7e52 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -576,8 +576,17 @@ unsigned int cpufreq_policy_transition_delay_us(struct cpufreq_policy *policy) > > latency = policy->cpuinfo.transition_latency / NSEC_PER_USEC; > if (latency) { > + unsigned int max_delay_us = 2 * MSEC_PER_SEC; > + > + /* > + * If the platform already has high transition_latency, use it > + * as-is. > + */ > + if (latency > max_delay_us) > + return latency; > + > /* > - * For platforms that can change the frequency very fast (< 10 > + * For platforms that can change the frequency very fast (< 2 > * us), the above formula gives a decent transition delay. But > * for platforms where transition_latency is in milliseconds, it > * ends up giving unrealistic values. > @@ -586,7 +595,7 @@ unsigned int cpufreq_policy_transition_delay_us(struct cpufreq_policy *policy) > * a reasonable amount of time after which we should reevaluate > * the frequency. > */ > - return min(latency * LATENCY_MULTIPLIER, (unsigned int)(2 * MSEC_PER_SEC)); > + return min(latency * LATENCY_MULTIPLIER, max_delay_us); > } > > return LATENCY_MULTIPLIER; > -- Applied as 6.9 material, thanks!
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 66cef33c4ec7..926a51cb7e52 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -576,8 +576,17 @@ unsigned int cpufreq_policy_transition_delay_us(struct cpufreq_policy *policy) latency = policy->cpuinfo.transition_latency / NSEC_PER_USEC; if (latency) { + unsigned int max_delay_us = 2 * MSEC_PER_SEC; + + /* + * If the platform already has high transition_latency, use it + * as-is. + */ + if (latency > max_delay_us) + return latency; + /* - * For platforms that can change the frequency very fast (< 10 + * For platforms that can change the frequency very fast (< 2 * us), the above formula gives a decent transition delay. But * for platforms where transition_latency is in milliseconds, it * ends up giving unrealistic values. @@ -586,7 +595,7 @@ unsigned int cpufreq_policy_transition_delay_us(struct cpufreq_policy *policy) * a reasonable amount of time after which we should reevaluate * the frequency. */ - return min(latency * LATENCY_MULTIPLIER, (unsigned int)(2 * MSEC_PER_SEC)); + return min(latency * LATENCY_MULTIPLIER, max_delay_us); } return LATENCY_MULTIPLIER;
Some platforms like Arm's Juno can have a high transition latency that can be larger than the 2ms cap introduced. If a driver report a transition_latency that is higher than the cap, then use it as-is. Update comment s/10/2/ to reflect the new cap of 2ms. Reported-by: Pierre Gondois <pierre.gondois@arm.com> Signed-off-by: Qais Yousef <qyousef@layalina.io> --- drivers/cpufreq/cpufreq.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)