On 12/12/24 11:06, Christian Loehle wrote: > On 12/12/24 07:03, Nick Chan wrote: >> The driver already assumes transitions will not take longer than >> APPLE_DVFS_TRANSITION_TIMEOUT in apple_soc_cpufreq_set_target(), so it >> makes little sense to set CPUFREQ_ETERNAL as the transition latency >> when the transistion latency is not given by the opp-table. >> >> Signed-off-by: Nick Chan <towinchenmi@xxxxxxxxx> > > Reviewed-by: Christian Loehle <christian.loehle@xxxxxxx> > >> --- >> drivers/cpufreq/apple-soc-cpufreq.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/cpufreq/apple-soc-cpufreq.c b/drivers/cpufreq/apple-soc-cpufreq.c >> index 94e57f055a5f..c9f31a3653e2 100644 >> --- a/drivers/cpufreq/apple-soc-cpufreq.c >> +++ b/drivers/cpufreq/apple-soc-cpufreq.c >> @@ -291,7 +291,7 @@ static int apple_soc_cpufreq_init(struct cpufreq_policy *policy) >> >> transition_latency = dev_pm_opp_get_max_transition_latency(cpu_dev); >> if (!transition_latency) >> - transition_latency = CPUFREQ_ETERNAL; >> + transition_latency = APPLE_DVFS_TRANSITION_TIMEOUT * 1000; s/1000/NSEC_PER_USEC would have been the cleaner choice in case you respin. >> >> policy->cpuinfo.transition_latency = transition_latency; >> policy->dvfs_possible_from_any_cpu = true; > >
