AMD Making It Easier To Switch To Their New P-State CPU Frequency Scaling Driver

Following our how-to guide for enabling the new AMD P-State driver that premiered in Linux 5.17 after finding many users were unsure to go about using this new CPU frequency scaling driver, AMD is now making it easier to switch from ACPI CPUFreq to AMD P-State.

As noted in the how-to article, while the likes of the Ubuntu Mainline Kernel PPA are building amd_pstate already as a kernel module, it's not trivial to switch to with ACPI CPUFreq taking precedence and getting in the way of loading the amd_pstate module. Using the "initcall_blacklist=acpi_cpufreq_init" kernel option detailed in the guide will block the ACPI CPUFreq driver from initializing and thus allowing the AMD P-State driver to go on and claim the supported AMD CPU. But with pending patches to the AMD P-State driver, that blacklisting won't be needed anymore for kernels building in ACPI CPUFreq but leaving AMD P-State as a module.

AMD engineer Mario Limonciello, who joined AMD's Linux client team last year, sent out a patch series improving the usability for this new driver. The patch series adds a new "replace" module option for AMD P-State to allow it to replace existing CPUFreq drivers when loaded. Additionally, another patch adds a module device table so the amd_pstate driver will auto-load if encountering an AMD CPU with ACPI CPPC supported (introduced with Zen 2 and a requirement for this driver).

So with these pending patches it would allow simply having amd_pstate.replace=1 as a kernel parameter to boot the system and use AMD P-State without blacklisting ACPI CPUFreq or rebuilding your kernel with this new driver built-in. This would also allow users to toss "options amd-pstate replace=1" into the /etc/modprobe.d directory on distributions like Ubuntu as another easy means of switching. Thus this convenient patch series is making things much simpler for the kernel builds out there having AMD P-State as a module and ultimately making it even easier for users to opt into using this new driver focused on better power efficiency.

This patch series isn't forcing AMD P-State by default or so, but we'll see if that comes up in a future kernel version once AMD P-State has proven itself. Right now these patches are residing just on the kernel mailing list while we'll see if they get picked up in time to try to make it into v5.18 or is held off until the v5.19 cycle.