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(-)

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);
-
 }
 
 /*
-- 
2.34.1

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>

-- 
Thanks and Regards
gautham.
> 
> Signed-off-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com>
> ---
>  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);
> -
>  }
>  
>  /*
> -- 
> 2.34.1
>

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);
> -
>   }
>   
>   /*