[AMD Official Use Only - General]

Hi Rafael:

> -----Original Message-----
> From: Rafael J. Wysocki <[email protected]>
> Sent: Tuesday, December 12, 2023 9:44 PM
> To: Meng, Li (Jassmine) <[email protected]>
> Cc: Rafael J . Wysocki <[email protected]>; Huang, Ray
> <[email protected]>; [email protected]; linux-
> [email protected]; [email protected]; [email protected]; Shuah
> Khan <[email protected]>; [email protected];
> Fontenot, Nathan <[email protected]>; Sharma, Deepak
> <[email protected]>; Deucher, Alexander
> <[email protected]>; Limonciello, Mario
> <[email protected]>; Huang, Shimmer
> <[email protected]>; Yuan, Perry <[email protected]>; Du,
> Xiaojian <[email protected]>; Viresh Kumar <[email protected]>;
> Borislav Petkov <[email protected]>; Oleksandr Natalenko
> <[email protected]>
> Subject: Re: [PATCH V12 4/7] cpufreq: Add a notification message that the
> highest perf has changed
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> On Wed, Dec 6, 2023 at 10:13 PM Rafael J. Wysocki <[email protected]>
> wrote:
> >
> > On Wed, Dec 6, 2023 at 9:58 PM Rafael J. Wysocki <[email protected]>
> wrote:
> > >
> > > On Tue, Dec 5, 2023 at 7:38 AM Meng Li <[email protected]> wrote:
> > > >
> > > > ACPI 6.5 section 8.4.6.1.1.1 specifies that Notify event 0x85 can
> > > > be emmitted to cause the the OSPM to re-evaluate the highest
> > > > performance
> > >
> > > Typos above.  Given the number of iterations of this patch, this is
> > > kind of disappointing.
> > >
> > > > register. Add support for this event.
> > >
> > > Also it would be nice to describe how this is supposed to work at
> > > least roughly, so it is not necessary to reverse-engineer the patch
> > > to find out that.
> > >
> > > > Tested-by: Oleksandr Natalenko <[email protected]>
> > > > Reviewed-by: Mario Limonciello <[email protected]>
> > > > Reviewed-by: Huang Rui <[email protected]>
> > > > Reviewed-by: Perry Yuan <[email protected]>
> > > > Signed-off-by: Meng Li <[email protected]>
> > > > Link:
> > > >
> https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model
> > > > .html#processor-device-notification-values
> > > > ---
> > > >  drivers/acpi/processor_driver.c |  6 ++++++
> > > >  drivers/cpufreq/cpufreq.c       | 13 +++++++++++++
> > > >  include/linux/cpufreq.h         |  5 +++++
> > > >  3 files changed, 24 insertions(+)
> > > >
> > > > diff --git a/drivers/acpi/processor_driver.c
> > > > b/drivers/acpi/processor_driver.c index 4bd16b3f0781..29b2fb68a35d
> > > > 100644
> > > > --- a/drivers/acpi/processor_driver.c
> > > > +++ b/drivers/acpi/processor_driver.c
> > > > @@ -27,6 +27,7 @@
> > > >  #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80
> > > >  #define ACPI_PROCESSOR_NOTIFY_POWER    0x81
> > > >  #define ACPI_PROCESSOR_NOTIFY_THROTTLING       0x82
> > > > +#define ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED      0x85
> > > >
> > > >  MODULE_AUTHOR("Paul Diefenbaugh");
> MODULE_DESCRIPTION("ACPI
> > > > Processor Driver"); @@ -83,6 +84,11 @@ static void
> > > > acpi_processor_notify(acpi_handle handle, u32 event, void *data)
> > > >                 
> > > > acpi_bus_generate_netlink_event(device->pnp.device_class,
> > > >                                                   
> > > > dev_name(&device->dev), event, 0);
> > > >                 break;
> > > > +       case ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED:
> > > > +               cpufreq_update_highest_perf(pr->id);
> > >
> > > And the design appears to be a bit ad-hoc here.
> > >
> > > Because why does it have anything to do with cpufreq?
> >
> > Well, clearly, cpufreq can be affected by this, but why would it be
> > not affected the same way as in the
> ACPI_PROCESSOR_NOTIFY_PERFORMANCE
> > case?
> >
> > That is, why isn't cpufreq_update_limits() the right thing to do?
>
> Seriously, I'm not going to apply this patch so long as my comments above
> are not addressed.
[Meng, Li (Jassmine)]
Sorry for the delayed reply to the email.
BIOS/AGESA is responsible to issue the Notify 0x85 to OS that the preferred 
core has changed.
It will only affect the ranking of the preferred core, not the impact policy 
limits.
AMD P-state driver will set the priority of the cores based on the preferred 
core ranking, and prioritize selecting higher priority core to run the task.

Reply via email to