Re: [PATCH v2] ACPI: Fix initial QoS constraint application order in PPC initialization

[李佳怡]

在 2025/7/21 21:27, Rafael J. Wysocki 写道:
> On Mon, Jul 21, 2025 at 5:26 AM Jiayi Li <lijiayi@xxxxxxxxxx> wrote:
> > This patch fixes an issue where _PPC frequency limits set by the BIOS
> > failed to take effect due to incorrect call ordering. Previously,
> > freq_qos_update_request() was being called before freq_qos_add_request(),
> > causing the constraint updates to be ignored. With this fix, the frequency
> > limits are now properly enforced as intended.
> > The original initialization sequence was:
> >
> > cpufreq_policy_online()
> >      acpi_cpufreq_cpu_init()
> >          acpi_processor_get_platform_limit()
> >              freq_qos_update_request(&perflib_req)
> >      blocking_notifier_call_chain(...)
> >          acpi_processor_ppc_init()
> >              freq_qos_add_request(&perflib_req)
> >
> > The new sequence explicitly ensures:
> >
> > cpufreq_policy_online()
> >      acpi_cpufreq_cpu_init()
> >          acpi_processor_get_platform_limit()
> >              freq_qos_update_request(&perflib_req)
> >      blocking_notifier_call_chain(...)
> >          acpi_processor_ppc_init()
> >              freq_qos_add_request(&perflib_req)
> > +           acpi_processor_get_platform_limit()
> > +               freq_qos_update_request(&perflib_req)
> >
> > The critical change adds an immediate platform limit update after the
> > QoS request is registered. This guarantees that the initial P-state
> > constraint is applied before any subsequent updates, resolving the window
> > where constraints could be applied out-of-order.
> >
> > Fixes: d15ce412737a ("ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier")
> > Signed-off-by: Jiayi Li <lijiayi@xxxxxxxxxx>
> > ---
> > v1 -> v2:
> > - Modify the commit.
> > - Add pr->performance check in acpi_processor_ppc_init loop.
> > ---
> > ---
> >   drivers/acpi/processor_perflib.c | 11 +++++++++++
> >   1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
> > index 64b8d1e19594..56f2b8354d62 100644
> > --- a/drivers/acpi/processor_perflib.c
> > +++ b/drivers/acpi/processor_perflib.c
> > @@ -173,6 +173,9 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
> >   {
> >          unsigned int cpu;
> >
> > +       if (ignore_ppc == 1)
> > +               return;
> > +
> >          for_each_cpu(cpu, policy->related_cpus) {
> >                  struct acpi_processor *pr = per_cpu(processors, cpu);
> >                  int ret;
> > @@ -180,6 +183,9 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
> >                  if (!pr)
> >                          continue;
> >
> > +               if (!pr->performance)
> > +                       continue;
> > +
> >                  /*
> >                   * Reset performance_platform_limit in case there is a stale
> >                   * value in it, so as to make it match the "no limit" QoS value
>
> Applied, but I have consolidated the pr and pr->performance checks above.
>
> I have also made some changes in the subject and changelog.
>
> Thanks!

Thanks for the review!

> > @@ -193,6 +199,11 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
> >                  if (ret < 0)
> >                          pr_err("Failed to add freq constraint for CPU%d (%d)\n",
> >                                 cpu, ret);
> > +
> > +               ret = acpi_processor_get_platform_limit(pr);
> > +               if (ret)
> > +                       pr_err("Failed to update freq constraint for CPU%d (%d)\n",
> > +                              cpu, ret);
> >          }
> >   }
> >
> > --