In this series, three feature control support for amd_pstate has been
added.

 1. EPP: User can control Energy Performance Preference (EPP) value,
which conveys user's performance vs energy preference to platform. This
feature is present on amd_pstate and intel_pstate active mode.

 2. amd_pstate mode switch: amd_pstate has various working modes such as
'active', 'passive' and 'guided', which can be changed dynamically. 

 3. Turbo boost: Turbo boost feature is present in amd_pstate as well as
acpi-cpufreq. By default this is enabled, but user can control this
feature dynamically.

These features can be controlled with `cpupower set` command. The
options are respectively --epp, --amd-pstate-mode, --turbo-boost

Also, make cpupower recognise amd-pstate-epp driver.

Changelog:
v2->v3:
- Use common prefix to recognise amd-pstate-epp driver.
- Picked up review tag from Mario.

v1->v2:
- Drop patch 1, which was amd-pstate-epp driver rename change.
- Picked ACKs from Ray.

Wyes Karny (5):
  cpupower: Recognise amd-pstate active mode driver
  cpupower: Add is_valid_path API
  cpupower: Add EPP value change support
  cpupower: Add support for amd_pstate mode change
  cpupower: Add turbo-boost support in cpupower

 tools/power/cpupower/lib/cpupower.c          |  7 +++
 tools/power/cpupower/lib/cpupower_intern.h   |  1 +
 tools/power/cpupower/utils/cpupower-set.c    | 65 +++++++++++++++++++-
 tools/power/cpupower/utils/helpers/helpers.h | 11 ++++
 tools/power/cpupower/utils/helpers/misc.c    | 57 ++++++++++++++++-
 5 files changed, 138 insertions(+), 3 deletions(-)

-- 
2.34.1

Hi,

sorry for the late answer, I wanted to give this a test, but could not
make it (yet).

My 2 cents on this one:

what Ray already mentioned is greatly appreciated: Find common APIs, not only 
AMD vs Intel, but general ones, outside of the driver specific sysfs dir, e.g.:
/sys/devices/system/cpu/cpufreq/...

But not at all costs and if the epp part is (AMD) specific and varies to others 
in meaning or in values, it has to be a specific file/API.

(Another Example/Request at the end)

And...: It would be nice to see some documentation in form of manpage 
enhancements. At least for the newly introduced arguments.
If not yet, there should be: possible value range, which machines (CPU flags, 
Zen 4, ...), if more complex technology, some kind of introduction or 
reference where to find things would be really great.

I wonder whether it could be possible to connect this with:
Documentation/admin-guide/pm/intel_pstate.rst
Documentation/admin-guide/pm/amd-pstate.rst

I guess there is a static web site address people could rely on where above
kernel docs are hosted forever?
Then it would make sense to link the cpupower manpage with it and keep the 
description short and avoid duplication?

             Thomas


Another Example/Request at the end:

One example I recently got asked for, the bug is private:
"cpupower is not returning max turbo active cores information on latest Intel 
processors."

Here are examples of 2 newer cpus that don't return the active core 
information like this: 
    3600 MHz max turbo 4 active cores
    3600 MHz max turbo 3 active cores
    3700 MHz max turbo 2 active cores
    3800 MHz max turbo 1 active cores

Not sure whether there finally is some kind of consolidation on turbo/boost/
dynamic/hw/bios interfaces in respect to turbo/boosting technology. But if 
anyhow possible and it makes sense, it would be really great to see one sysfs 
file exposed to userspace to read/enable/disable.

Possible cpufreqs (including or only) boost freqs, maybe with active cores if 
this is a general technique optionally added if avail?

Nothing which has to be implemented at all costs and right now, just an idea 
on how things could be consolidated at some point of time which might be wise 
to think about now already...

On 7/14/23 05:19, Thomas Renninger wrote:
> Hi,
> 
> sorry for the late answer, I wanted to give this a test, but could not
> make it (yet).
> 
> My 2 cents on this one:
> 
> what Ray already mentioned is greatly appreciated: Find common APIs, not only
> AMD vs Intel, but general ones, outside of the driver specific sysfs dir, e.g.:
> /sys/devices/system/cpu/cpufreq/...
> 
> But not at all costs and if the epp part is (AMD) specific and varies to others
> in meaning or in values, it has to be a specific file/API.
> 
> (Another Example/Request at the end)
> 
> And...: It would be nice to see some documentation in form of manpage
> enhancements. At least for the newly introduced arguments.
> If not yet, there should be: possible value range, which machines (CPU flags,
> Zen 4, ...), if more complex technology, some kind of introduction or
> reference where to find things would be really great.
> 
> I wonder whether it could be possible to connect this with:
> Documentation/admin-guide/pm/intel_pstate.rst
> Documentation/admin-guide/pm/amd-pstate.rst
> 
> I guess there is a static web site address people could rely on where above
> kernel docs are hosted forever?
> Then it would make sense to link the cpupower manpage with it and keep the
> description short and avoid duplication?
> 
>               Thomas
> 
> 
> Another Example/Request at the end:
> 
> One example I recently got asked for, the bug is private:
> "cpupower is not returning max turbo active cores information on latest Intel
> processors."
> 
> Here are examples of 2 newer cpus that don't return the active core
> information like this:
>      3600 MHz max turbo 4 active cores
>      3600 MHz max turbo 3 active cores
>      3700 MHz max turbo 2 active cores
>      3800 MHz max turbo 1 active cores
> 
> Not sure whether there finally is some kind of consolidation on turbo/boost/
> dynamic/hw/bios interfaces in respect to turbo/boosting technology. But if
> anyhow possible and it makes sense, it would be really great to see one sysfs
> file exposed to userspace to read/enable/disable.
> 
> Possible cpufreqs (including or only) boost freqs, maybe with active cores if
> this is a general technique optionally added if avail?
> 
> Nothing which has to be implemented at all costs and right now, just an idea
> on how things could be consolidated at some point of time which might be wise
> to think about now already...
> 

I applied these for Linux 6.6-rc1 - ran quick tests.

Please act on feedback from Thomas and send me patches on top of

https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux.git/log/?h=cpupower

thanks,
-- Shuah