Documentation/ABI/testing/sysfs-amd-pmf | 10 +++ .../ABI/testing/sysfs-platform_profile | 1 + drivers/acpi/platform_profile.c | 1 + drivers/platform/x86/amd/pmf/Makefile | 1 + drivers/platform/x86/amd/pmf/core.c | 9 ++ drivers/platform/x86/amd/pmf/manual.c | 88 +++++++++++++++++++ drivers/platform/x86/amd/pmf/pmf.h | 5 ++ drivers/platform/x86/amd/pmf/sps.c | 4 + include/linux/platform_profile.h | 1 + 9 files changed, 120 insertions(+) create mode 100644 drivers/platform/x86/amd/pmf/manual.c
From: Mario Limonciello <mario.limonciello@amd.com> There are two major ways to tune platform performance in Linux: * ACPI platform profile * Manually tuning APU performance Changing the ACPI platform profile is a "one stop shop" to change performance limits and fan curves all at the same time. On AMD systems the manual tuning methods typically involve changing values of settings such as fPPT, sPPT or SPL. The problem with changing these settings manually is that the definition of the ACPI platform profile if supported by the hardware is no longer accurate. At best this can cause misrepresenting the state of the platform to userspace and at worst can cause the state machine into an invalid state. The existence and continued development of projects such as ryzenadj which manipulate debugging interfaces show there is a demand for manually tuning performance. Furthermore some systems (such as ASUS and Lenovo handhelds) offer an ACPI-WMI interface for changing these settings. If using anything outside that WMI interface the state will be wrong. If using that WMI interface the platform profile will be wrong. This series introduces a "custom" ACPI platform profile and adds support for the AMD PMF driver to use it when a user has enabled manual adjustments. If agreeable a similar change should be made to asus-armoury and any other drivers that export the ability to change these settings but also a platform profile. Mario Limonciello (2): ACPI: Add support for a 'custom' profile platform/x86/amd: pmf: Add manual control support Documentation/ABI/testing/sysfs-amd-pmf | 10 +++ .../ABI/testing/sysfs-platform_profile | 1 + drivers/acpi/platform_profile.c | 1 + drivers/platform/x86/amd/pmf/Makefile | 1 + drivers/platform/x86/amd/pmf/core.c | 9 ++ drivers/platform/x86/amd/pmf/manual.c | 88 +++++++++++++++++++ drivers/platform/x86/amd/pmf/pmf.h | 5 ++ drivers/platform/x86/amd/pmf/sps.c | 4 + include/linux/platform_profile.h | 1 + 9 files changed, 120 insertions(+) create mode 100644 drivers/platform/x86/amd/pmf/manual.c -- 2.43.0
Thanks Mario, On Wed, Sep 25, 2024, at 10:59 PM, Mario Limonciello wrote: > From: Mario Limonciello <mario.limonciello@amd.com> > > There are two major ways to tune platform performance in Linux: > * ACPI platform profile > * Manually tuning APU performance > > Changing the ACPI platform profile is a "one stop shop" to change > performance limits and fan curves all at the same time. > > On AMD systems the manual tuning methods typically involve changing > values of settings such as fPPT, sPPT or SPL. > > The problem with changing these settings manually is that the definition > of the ACPI platform profile if supported by the hardware is no longer > accurate. At best this can cause misrepresenting the state of the > platform to userspace and at worst can cause the state machine into an > invalid state. > > The existence and continued development of projects such as ryzenadj which > manipulate debugging interfaces show there is a demand for manually tuning > performance. > > Furthermore some systems (such as ASUS and Lenovo handhelds) offer an > ACPI-WMI interface for changing these settings. If using anything outside > that WMI interface the state will be wrong. If using that WMI interface > the platform profile will be wrong. > > This series introduces a "custom" ACPI platform profile and adds support > for the AMD PMF driver to use it when a user has enabled manual > adjustments. > > If agreeable a similar change should be made to asus-armoury and any other > drivers that export the ability to change these settings but also a > platform profile. > As someone who supports customers on Lenovo devices and hits the occasional situation where a user has made strange tweaks to different power related settings, and then complains about power or thermal issues - I love the idea that it can be made clear the system has been 'adjusted' in a non standard way. I can also see why users would want interfaces to do those changes. Some suggestions: I'm wondering if we can make it so a driver can register only a 'custom' profile as an extra profile handler? The thinking here is the custom setting in this series is implemented for the amd sps driver, and therefore on a regular Lenovo laptop wouldn't be used, as the thinkpad_acpi driver will grab the profile slot, Users on Lenovo systems aren't going to be able to get at these extra tweaks (unless they unload thinkpad_acpi, which has other side effects). If the sps driver can offer a custom mode, separately from thinkpad_acpi, then users can tweak settings to their hearts content but get back to regular mode when done. I also think there needs to be a way that when you switch from custom back to a 'regular' profile that it would do a clean up of anything tweaked. e.g. when switching away from custom the ppd driver should call a 'custom mode cleanup' function, so things can be undone and returned to how they were when it was started. Mark
On 9/26/2024 08:58, Mark Pearson wrote: > Thanks Mario, > > On Wed, Sep 25, 2024, at 10:59 PM, Mario Limonciello wrote: >> From: Mario Limonciello <mario.limonciello@amd.com> >> >> There are two major ways to tune platform performance in Linux: >> * ACPI platform profile >> * Manually tuning APU performance >> >> Changing the ACPI platform profile is a "one stop shop" to change >> performance limits and fan curves all at the same time. >> >> On AMD systems the manual tuning methods typically involve changing >> values of settings such as fPPT, sPPT or SPL. >> >> The problem with changing these settings manually is that the definition >> of the ACPI platform profile if supported by the hardware is no longer >> accurate. At best this can cause misrepresenting the state of the >> platform to userspace and at worst can cause the state machine into an >> invalid state. >> >> The existence and continued development of projects such as ryzenadj which >> manipulate debugging interfaces show there is a demand for manually tuning >> performance. >> >> Furthermore some systems (such as ASUS and Lenovo handhelds) offer an >> ACPI-WMI interface for changing these settings. If using anything outside >> that WMI interface the state will be wrong. If using that WMI interface >> the platform profile will be wrong. >> >> This series introduces a "custom" ACPI platform profile and adds support >> for the AMD PMF driver to use it when a user has enabled manual >> adjustments. >> >> If agreeable a similar change should be made to asus-armoury and any other >> drivers that export the ability to change these settings but also a >> platform profile. >> > > As someone who supports customers on Lenovo devices and hits the occasional situation where a user has made strange tweaks to different power related settings, and then complains about power or thermal issues - I love the idea that it can be made clear the system has been 'adjusted' in a non standard way. I can also see why users would want interfaces to do those changes. JFYI we're going to do something really similar in amdgpu when people have enabled overclocking. That's part of the inspiration for this RFC. https://lore.kernel.org/amd-gfx/CADnq5_M+vxGV6y8oEQHC+-CcqV-vW9ND4SsRHqHKbwR_b0iJ9g@mail.gmail.com/T/#m1d69399c3e799ea1ef2014a27fd6e555f9e70ba0 > > Some suggestions: > > I'm wondering if we can make it so a driver can register only a 'custom' profile as an extra profile handler? > > The thinking here is the custom setting in this series is implemented for the amd sps driver, and therefore on a regular Lenovo laptop wouldn't be used, as the thinkpad_acpi driver will grab the profile slot, Users on Lenovo systems aren't going to be able to get at these extra tweaks (unless they unload thinkpad_acpi, which has other side effects). Well the RFC was just to show it for the AMD PMF driver, but I think that thinkpad_acpi, asus_armoury etc could all potentially implement the 'custom' bit too if they offer an ACPI-WMI interface to similar settings. > > If the sps driver can offer a custom mode, separately from thinkpad_acpi, then users can tweak settings to their hearts content but get back to regular mode when done. > > I also think there needs to be a way that when you switch from custom back to a 'regular' profile that it would do a clean up of anything tweaked. e.g. when switching away from custom the ppd driver should call a 'custom mode cleanup' function, so things can be undone and returned to how they were when it was started. > > Mark I guess what you're proposing is that multiple drivers register as profile handlers and they might not all export the same features. If we did something like this we could instead have the core call callbacks for all platform profile handlers. We could also drop a pile of quirks from amd-pmf where there are some ASUS systems that advertise SPS in in the PMF framework and also asus-wmi provides it. If I'm following you right, I generally like this idea.
On Thu, Sep 26, 2024, at 2:14 PM, Mario Limonciello wrote: > On 9/26/2024 08:58, Mark Pearson wrote: >> Thanks Mario, >> >> On Wed, Sep 25, 2024, at 10:59 PM, Mario Limonciello wrote: >>> From: Mario Limonciello <mario.limonciello@amd.com> >>> >>> There are two major ways to tune platform performance in Linux: >>> * ACPI platform profile >>> * Manually tuning APU performance >>> >>> Changing the ACPI platform profile is a "one stop shop" to change >>> performance limits and fan curves all at the same time. >>> >>> On AMD systems the manual tuning methods typically involve changing >>> values of settings such as fPPT, sPPT or SPL. >>> >>> The problem with changing these settings manually is that the definition >>> of the ACPI platform profile if supported by the hardware is no longer >>> accurate. At best this can cause misrepresenting the state of the >>> platform to userspace and at worst can cause the state machine into an >>> invalid state. >>> >>> The existence and continued development of projects such as ryzenadj which >>> manipulate debugging interfaces show there is a demand for manually tuning >>> performance. >>> >>> Furthermore some systems (such as ASUS and Lenovo handhelds) offer an >>> ACPI-WMI interface for changing these settings. If using anything outside >>> that WMI interface the state will be wrong. If using that WMI interface >>> the platform profile will be wrong. >>> >>> This series introduces a "custom" ACPI platform profile and adds support >>> for the AMD PMF driver to use it when a user has enabled manual >>> adjustments. >>> >>> If agreeable a similar change should be made to asus-armoury and any other >>> drivers that export the ability to change these settings but also a >>> platform profile. >>> >> >> As someone who supports customers on Lenovo devices and hits the occasional situation where a user has made strange tweaks to different power related settings, and then complains about power or thermal issues - I love the idea that it can be made clear the system has been 'adjusted' in a non standard way. I can also see why users would want interfaces to do those changes. > > JFYI we're going to do something really similar in amdgpu when people > have enabled overclocking. That's part of the inspiration for this RFC. > > https://lore.kernel.org/amd-gfx/CADnq5_M+vxGV6y8oEQHC+-CcqV-vW9ND4SsRHqHKbwR_b0iJ9g@mail.gmail.com/T/#m1d69399c3e799ea1ef2014a27fd6e555f9e70ba0 > Nice :) >> >> Some suggestions: >> >> I'm wondering if we can make it so a driver can register only a 'custom' profile as an extra profile handler? >> >> The thinking here is the custom setting in this series is implemented for the amd sps driver, and therefore on a regular Lenovo laptop wouldn't be used, as the thinkpad_acpi driver will grab the profile slot, Users on Lenovo systems aren't going to be able to get at these extra tweaks (unless they unload thinkpad_acpi, which has other side effects). > > Well the RFC was just to show it for the AMD PMF driver, but I think > that thinkpad_acpi, asus_armoury etc could all potentially implement the > 'custom' bit too if they offer an ACPI-WMI interface to similar settings. > >> >> If the sps driver can offer a custom mode, separately from thinkpad_acpi, then users can tweak settings to their hearts content but get back to regular mode when done. >> >> I also think there needs to be a way that when you switch from custom back to a 'regular' profile that it would do a clean up of anything tweaked. e.g. when switching away from custom the ppd driver should call a 'custom mode cleanup' function, so things can be undone and returned to how they were when it was started. >> >> Mark > > I guess what you're proposing is that multiple drivers register as > profile handlers and they might not all export the same features. > > If we did something like this we could instead have the core call > callbacks for all platform profile handlers. We could also drop a pile > of quirks from amd-pmf where there are some ASUS systems that advertise > SPS in in the PMF framework and also asus-wmi provides it. > > If I'm following you right, I generally like this idea. Yep - that was the idea. This feels like a step towards giving more control to power users - whilst keeping the basic simple for regular folk. I can imagine utilities that would use this to enable specific configurations, via the custom profile mode, for many different scenario's; whilst still allowing a user to get back to the tested and vendor approved setting if things go badly. Mark
© 2016 - 2024 Red Hat, Inc.