> >> 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 think I considered that as part of my userspace software and reached the conclusion that if there is an EC, for most users it is best to program it and forgo the extra features. Otherwise they get weird bugs and conflicts, such as incorrect fan curves or their settings being reset randomly. On the Legion and Thinkpad series, the hardware binds would also cause this (Fn + BMH)/(Legion Go L + Y), and for Legion series specifically, the power button will have the wrong color. So I do not know if it is worth exploring as having it controllable from userspace in such a clean way. Of course, tinkerers could mess around by disabling modules to try something out and that would work fine, but I do not think it will be usable day to day. I personally gave up on the idea. However, having a load order and falling back to amd-pmf does have merit. E.g., the legion go will need a quirk for pmf too, and probably most laptop lines going forward. So that should be explored. > >> > >> 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. I will note that for handhelds, having a TDP slider is basic functionality. So we need to find a way to give this control to users without tainting the kernel or requiring special workarounds in the case the manufacturer did not provide a WMI interface. This PR is a step in that direction, but then we need to deal with hardware limits and such to make sure it is safe. As far as fPPT and sPPt go, I will be honest and say I never had a user ask for them. However, unless the driver implements a LUT or some basic logic to enable/disable some sort of boost, they will need to be exposed to sysfs so userspace can do it. It does not mean that userspace will need to show that to users, just that it will do the interpolation to apply the correct boost if that is requested. Here I will note Legion Space did not do that on the Legion Go on WIndows for the first 5-6 months of its release. This lead to custom mode being completely broken from a user's perspective. Since the device is STT, if the user set the spl to 10W, well sPPT was 32W and fPPT was 43W so the device just kept boosting forever. However, one of the first BIOS versions added sPPT and fPPT to WMI, so we never had that problem in Linux. Now, Legion Space added sPPT and fPPT as sliders, which just causes annoyance for users, as they have to edit 3 sliders instead of one to get their desired performance level. To that end, both Asus and Lenovo offer sPPT and fPPT adjustment, so there is no risk with exposing that to userspace in Linux specifically. As long as the limits are bounded. Antheas
