| Message ID | 20250205112523.201101-9-dhananjay.ugwekar@amd.com (mailing list archive) |
|---|---|
| State | New |
| Delegated to: | Mario Limonciello |
| Headers | show |
| Series | cpufreq/amd-pstate: Fixes and optimizations | expand |
On 2/5/2025 05:25, Dhananjay Ugwekar wrote: > The update_limits callback is only called in two conditions. > > * When the preferred core rankings change. In which case, we just need to > change the prefcore ranking in the cpudata struct. As there are no changes > to any of the perf values, there is no need to call cpufreq_update_policy() > > * When the _PPC ACPI object changes, i.e. the highest allowed Pstate > changes. The _PPC object is only used for a table based cpufreq driver > like acpi-cpufreq, hence is irrelevant for CPPC based amd-pstate. > > Hence, the cpufreq_update_policy() call becomes unnecessary and can be > removed. > > Signed-off-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> I'll queue this for 6.15. > --- > drivers/cpufreq/amd-pstate.c | 4 ---- > 1 file changed, 4 deletions(-) > > diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c > index 346fac646eba..107ad953ce43 100644 > --- a/drivers/cpufreq/amd-pstate.c > +++ b/drivers/cpufreq/amd-pstate.c > @@ -852,10 +852,6 @@ static void amd_pstate_update_limits(unsigned int cpu) > sched_set_itmt_core_prio((int)cur_high, cpu); > } > cpufreq_cpu_put(policy); > - > - if (!highest_perf_changed) > - cpufreq_update_policy(cpu); > - > } > > /*
On Wed, Feb 05, 2025 at 11:25:19AM +0000, Dhananjay Ugwekar wrote: > The update_limits callback is only called in two conditions. > > * When the preferred core rankings change. In which case, we just need to > change the prefcore ranking in the cpudata struct. As there are no changes > to any of the perf values, there is no need to call cpufreq_update_policy() > > * When the _PPC ACPI object changes, i.e. the highest allowed Pstate > changes. The _PPC object is only used for a table based cpufreq driver > like acpi-cpufreq, hence is irrelevant for CPPC based amd-pstate. > > Hence, the cpufreq_update_policy() call becomes unnecessary and can be > removed. Thanks for the cleanup. Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c index 346fac646eba..107ad953ce43 100644 --- a/drivers/cpufreq/amd-pstate.c +++ b/drivers/cpufreq/amd-pstate.c @@ -852,10 +852,6 @@ static void amd_pstate_update_limits(unsigned int cpu) sched_set_itmt_core_prio((int)cur_high, cpu); } cpufreq_cpu_put(policy); - - if (!highest_perf_changed) - cpufreq_update_policy(cpu); - } /*
The update_limits callback is only called in two conditions. * When the preferred core rankings change. In which case, we just need to change the prefcore ranking in the cpudata struct. As there are no changes to any of the perf values, there is no need to call cpufreq_update_policy() * When the _PPC ACPI object changes, i.e. the highest allowed Pstate changes. The _PPC object is only used for a table based cpufreq driver like acpi-cpufreq, hence is irrelevant for CPPC based amd-pstate. Hence, the cpufreq_update_policy() call becomes unnecessary and can be removed. Signed-off-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com> --- drivers/cpufreq/amd-pstate.c | 4 ---- 1 file changed, 4 deletions(-)