There has recently been some news coverage about `amd-pstate` being in
5.17, but this news also mentioned that it's a bit difficult to use.

You need to either block init calls, or compile the module into the kernel
to force it to take precedence over acpi-cpufreq.

This series aims to improve the usability of amd-pstate so that distros
can compile as a module, but users can still use it (relatively) easily.

A new module parameter is included that will force amd-pstate to take
precedence and a module table to let it load automatically on such systems.

With the patches in this series a user can make a file
/etc/modprobe.d/amd-pstate.conf:

options amd-pstate replace=1

Then upon the next reboot amd-pstate should load automatically even if
acpi-cpufreq was included on the system.
Mario Limonciello (3):
  cpufreq: Allow passing NULL as the argument for unregistering a driver
  cpufreq: amd-pstate: Allow replacing existing cpufreq drivers when
    loaded
  cpufreq: amd-pstate: Add a module device table

 drivers/cpufreq/amd-pstate.c | 19 ++++++++++++++++---
 drivers/cpufreq/cpufreq.c    |  4 ++--
 2 files changed, 18 insertions(+), 5 deletions(-)

-- 
2.34.1

On Fri, Mar 25, 2022 at 01:42:25PM +0800, Limonciello, Mario wrote:
> There has recently been some news coverage about `amd-pstate` being in
> 5.17, but this news also mentioned that it's a bit difficult to use.
> 
> You need to either block init calls, or compile the module into the kernel
> to force it to take precedence over acpi-cpufreq.
> 
> This series aims to improve the usability of amd-pstate so that distros
> can compile as a module, but users can still use it (relatively) easily.
> 
> A new module parameter is included that will force amd-pstate to take
> precedence and a module table to let it load automatically on such systems.
> 
> With the patches in this series a user can make a file
> /etc/modprobe.d/amd-pstate.conf:
> 
> options amd-pstate replace=1

Actually, because the amd-pstate is fairly new for current distos, we can
modify /etc/modules-load.d/modules.conf to add one line "amd_pstate" to
inform the system this module should be loaded at boot time.

But your method also looks fine for me as well, the amd-pstate can force to
replace the acpi-cpufreq. I am not sure whether anyone objects to this way.

Thanks,
Ray

> 
> Then upon the next reboot amd-pstate should load automatically even if
> acpi-cpufreq was included on the system.
> Mario Limonciello (3):
>   cpufreq: Allow passing NULL as the argument for unregistering a driver
>   cpufreq: amd-pstate: Allow replacing existing cpufreq drivers when
>     loaded
>   cpufreq: amd-pstate: Add a module device table
> 
>  drivers/cpufreq/amd-pstate.c | 19 ++++++++++++++++---
>  drivers/cpufreq/cpufreq.c    |  4 ++--
>  2 files changed, 18 insertions(+), 5 deletions(-)
> 
> -- 
> 2.34.1
>

[Public]



> -----Original Message-----
> From: Huang, Ray <Ray.Huang@amd.com>
> Sent: Sunday, March 27, 2022 06:56
> To: Limonciello, Mario <Mario.Limonciello@amd.com>
> Cc: Rafael J . Wysocki <rafael@kernel.org>; Viresh Kumar
> <viresh.kumar@linaro.org>; open list:AMD PSTATE DRIVER <linux-
> pm@vger.kernel.org>; open list <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH 0/3] Improve usability for amd-pstate
> 
> On Fri, Mar 25, 2022 at 01:42:25PM +0800, Limonciello, Mario wrote:
> > There has recently been some news coverage about `amd-pstate` being in
> > 5.17, but this news also mentioned that it's a bit difficult to use.
> >
> > You need to either block init calls, or compile the module into the kernel
> > to force it to take precedence over acpi-cpufreq.
> >
> > This series aims to improve the usability of amd-pstate so that distros
> > can compile as a module, but users can still use it (relatively) easily.
> >
> > A new module parameter is included that will force amd-pstate to take
> > precedence and a module table to let it load automatically on such systems.
> >
> > With the patches in this series a user can make a file
> > /etc/modprobe.d/amd-pstate.conf:
> >
> > options amd-pstate replace=1
> 
> Actually, because the amd-pstate is fairly new for current distos, we can
> modify /etc/modules-load.d/modules.conf to add one line "amd_pstate" to
> inform the system this module should be loaded at boot time.

Actually I don't believe that would work in the case that acpi-cpufreq is built-in
or gets loaded first.

> 
> But your method also looks fine for me as well, the amd-pstate can force to
> replace the acpi-cpufreq. I am not sure whether anyone objects to this way.

Thanks for your suggestions in the series, I'll adopt them for v2.

> 
> Thanks,
> Ray
> 
> >
> > Then upon the next reboot amd-pstate should load automatically even if
> > acpi-cpufreq was included on the system.
> > Mario Limonciello (3):
> >   cpufreq: Allow passing NULL as the argument for unregistering a driver
> >   cpufreq: amd-pstate: Allow replacing existing cpufreq drivers when
> >     loaded
> >   cpufreq: amd-pstate: Add a module device table
> >
> >  drivers/cpufreq/amd-pstate.c | 19 ++++++++++++++++---
> >  drivers/cpufreq/cpufreq.c    |  4 ++--
> >  2 files changed, 18 insertions(+), 5 deletions(-)
> >
> > --
> > 2.34.1
> >