On Fri, Dec 24, 2021 at 2:05 AM Huang Rui [off-list ref] wrote:

Hi all,

Merry Christmas & Happy New Year!

We would like to introduce a new AMD CPU frequency control mechanism as the
AMD P-State driver for modern AMD Zen based CPU series in Linux Kernel.
The new mechanism is based on Collaborative processor performance control
(CPPC) which is finer grain frequency management than legacy ACPI hardware
P-States. Current AMD CPU platforms are using the ACPI P-states driver to
manage CPU frequency and clocks with switching only in 3 P-states. AMD
P-State is to replace the ACPI P-states controls, allows a flexible,
low-latency interface for the Linux kernel to directly communicate the
performance hints to hardware.

AMD P-State leverages the Linux kernel governors such as *schedutil*,
*ondemand*, etc. to manage the performance hints which are provided by CPPC
hardware functionality. The first version for AMD P-State is to support one
of the Zen3 processors, and we will support more in future after we verify
the hardware and SBIOS functionalities.

There are two types of hardware implementations for AMD P-State: one is full
MSR support and another is shared memory support. It can use
X86_FEATURE_CPPC feature flag to distinguish the different types.

Using the new AMD P-State method + kernel governors (*schedutil*,
*ondemand*, ...) to manage the frequency update is the most appropriate
bridge between AMD Zen based hardware processor and Linux kernel, the
processor is able to adjust to the most efficiency frequency according to
the kernel scheduler loading.

[cut]

Actually, the AMD P-State driver doesn't change the physical maximum
frequency capacity in the processor. But it's able to provide the finer
grain performance control range instead of legacy 3 P-States. It has a
better performance and power efficiency than before. We will continue
optimize AMD P-State function on kernel governors to support different types
of processors such as mobile latop, performance desktop, and etc.

[cut]

Huang Rui (11):
  x86/cpufeatures: Add AMD Collaborative Processor Performance Control
    feature flag
  x86/msr: Add AMD CPPC MSR definitions
  cpufreq: amd-pstate: Introduce a new AMD P-State driver to support
    future processors
  cpufreq: amd-pstate: Add fast switch function for AMD P-State
  cpufreq: amd-pstate: Introduce the support for the processors with
    shared memory solution
  cpufreq: amd-pstate: Add trace for AMD P-State module
  cpufreq: amd-pstate: Add boost mode support for AMD P-State
  cpufreq: amd-pstate: Add AMD P-State frequencies attributes
  cpufreq: amd-pstate: Add AMD P-State performance attributes
  Documentation: amd-pstate: Add AMD P-State driver introduction
  MAINTAINERS: Add AMD P-State driver maintainer entry

Jinzhou Su (1):
  ACPI: CPPC: Add CPPC enable register function

Mario Limonciello (1):
  ACPI: CPPC: Check present CPUs for determining _CPC is valid

Steven Noonan (1):
  ACPI: CPPC: Implement support for SystemIO registers

 Documentation/admin-guide/acpi/cppc_sysfs.rst |   2 +
 Documentation/admin-guide/pm/amd-pstate.rst   | 383 +++++++++++
 .../admin-guide/pm/working-state.rst          |   1 +
 MAINTAINERS                                   |   7 +
 arch/x86/include/asm/cpufeatures.h            |   1 +
 arch/x86/include/asm/msr-index.h              |  17 +
 drivers/acpi/cppc_acpi.c                      |  99 ++-
 drivers/cpufreq/Kconfig.x86                   |  17 +
 drivers/cpufreq/Makefile                      |   5 +
 drivers/cpufreq/amd-pstate-trace.c            |   2 +
 drivers/cpufreq/amd-pstate-trace.h            |  77 +++
 drivers/cpufreq/amd-pstate.c                  | 643 ++++++++++++++++++
 include/acpi/cppc_acpi.h                      |   5 +
 13 files changed, 1255 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/admin-guide/pm/amd-pstate.rst
 create mode 100644 drivers/cpufreq/amd-pstate-trace.c
 create mode 100644 drivers/cpufreq/amd-pstate-trace.h
 create mode 100644 drivers/cpufreq/amd-pstate.c

--

I'm queuing up this series for 5.17 with the assumption that all of
the comments on patch 2 have been addressed and that Steve will not
hate patch 9.

Thanks!