The recommendation from Framework is to use PPD (power-profiles-daemon) on Linux with the new AMD Ryzen 7040U board. According to the guide:
For Framework Laptop 13 AMD Ryzen™ 7040 Series configurations, you will absolutely want to use power-profiles-daemon for the absolute best experience. Do NOT use TLP. Without getting too detailed, there are things happening behind the scenes that require PPD for the best experience for our Linux customers.
However, after reading the code/docs for PPD, it’s pretty clear that it does exactly one thing: it sets the platform profile (via /sys/firmware/acpi/platform_profile) and nothing else, at least on a Framework Laptop. In other words, it doesn’t adjust power saving for other devices and it doesn’t touch AMD P-States.
Could someone from Framework comment on the “things happening behind the scenes” and why setting just the platform profile (ignoring p-states, etc.) is sufficient? And/or why one shouldn’t configure the amd_pstate_epp driver?
TLP, on the other hand, can do the exact same thing (set the power profile), while also configuring the p-state driver, etc.
As this is a user forum, I will let you know that there is no guarantee that Framework staff will respond here (though there is a pretty good chance as Matt and Loell (the two linux support members) do check the forums a lot. You will get a guaranteed response if you send a message to Framework support, though they are currently dealing with long queues, so it could take some time for them to respond. If you don’t get the response you want from an employee here for a while, I would send a message to support, then post the response they give you here.
One of PPD’s main optimization is it doesn’t interfere with AMD’s suspend.
Also a contact on AMD’s side has expressed that TLP will likely interfere with AMD’s suspend.
Also a contact on AMD’s side has expressed that TLP will likely interfere with AMD’s suspend.
I totally get recommending PPD from a support perspective as it’s very predictable. TLP is pretty powerful and difficult to configure correctly (although it can be configured to behave identically to PPD if so desired).
Unfortunately, PPD just doesn’t do half of what TLP does and, well:
It suggests that the other power-saving features in TLP should be enabled by default, but that’s not going to be the case for many (nearly all) users.
There’s an on going discussion about supporting both the AMD P-State EPP driver along with platform profiles.
I’m guessing @Mario_Limonciello can likely weigh in on this question if he has a moment.
“This project is archived and cannot be commented on.”, so it looks like the discussion isn’t really active anymore and PPD isn’t actively developed anymore at the moment.
Yes, it’s currently archived. However there is discussion to replace it with tuneD and let tuneD provide a compatible dbus interface. You can read more about it in the Fedora change proposal.
You are correct this is a deficiency in the last release of power profiles daemon.
Not only an ongoing discussion, there was a merge request that was being reviewed that added amd-pstate-epp support as well. When the project got archived that merge request got discarded. If not for the fact that tuneD is supposed to eventually replace PPD it might have made sense to fork the project.
The really important part of power profiles daemon is that it specifically has a path to the ACPI platform profile which on the AMD Framework platform is backed by the amd-pmf driver. The changes made to ACPI platform profiles have a path from the kernel to the BIOS to Framework’s EC which allow changing APU coefficients. It’s important that two entities don’t fight over these coefficients because Framework has extra logic in the EC which allows taking into account things like a 65W power supply vs a 90W power supply and what the APU can actually do with more power.
If you try changing these yourself outside of the EC something is going to stomp on the other and you’ll get unexpected results.
I don’t have any specifics to share to this thread but yes; this is something that has been observed. Aggressive configurations in TLP to override runtime PM behavior in the kernel will cause problems for the system; particularly at suspend. All of the important drivers for the AMD Framework systems have correct default kernel policies in the upstream kernel.
I know that software like powertop advertises possible tunables marked as Bad for some things like runtime PM for things like I2C adapters, PCI bridges and PCIe data fabric endpoints, but in practice these don’t matter.
IMO if you still find something that can be configured by tools like powertop or TLP that does have a measurable positive impact it means that a kernel policy knob default should be discussed.
One other thing that’s really important for a good experience is that both GNOME and KDE natively integrate with it. If you install Fedora or Ubuntu it just works.
To support that. I’ have completely switched from PPD to TLP with all settings to maximal power save on Bat and maximal performance on AC for a week and i had no issues so far. There are no Problems with suspend and no problems while switching from AC to Bat and back. The difference between TLP and PPD regarding Battery usage is big. Using PPD in different workloads the power drain is always 2-4W higher than using TLP.
If you’re seeing better runtime power draw with a TLP config, I suggest looking at measuring power efficiency (using the rapl interface). If you’re less efficient at lower power consumption are you actually better off? It’s a trade off.
Also make sure your measurements are specifically done on battery. Remember framework adjusts APU coefficients from their EC based on adapter connected.
Also, if you can please narrow down specifically what about your config is improving things it can be used to discuss better defaults without TLP in the picture. My knee jerk reaction (guess) would be screen brightness is the biggest contributor which can have a very dramatic impact.
[quote=“Mario_Limonciello, post:9, topic:39423”]
The really important part of power profiles daemon is that it specifically has a path to the ACPI platform profile which on the AMD Framework platform is backed by the amd-pmf driver. The changes made to ACPI platform profiles have a path from the kernel to the BIOS to Framework’s EC which allow changing APU coefficients.[/quote]
TLP allows configuring the ACPI Platform Profile via:
Yeah, but for anyone not using GNOME/KDE, it doesn’t appear to do anything unless manually invoked (which is probably a major source of “this doesn’t work” complaints). And even then, it won’t, e.g., adjust wifi power saving, etc (although you may be right that the defaults here are sufficient).
Sorry I don’t have an index of information here to offer on which knobs are safe and which aren’t. Early on in hardware bringup adding TLP was introducing a lot of instability, so we focused on only changing what was needed.
The two things that I know for sure are safe are changing the EPP policy and platform profile. If you find others that you want to do make sure that you properly profile them and confirm energy consumption and efficiency with the changes.
Those specific settings should be fine and make sense to me.
I’m human. If I’m wrong and you found one that really does help feel free to profile it and raise it for discussion.
Aligning EPP balance_power with platform power low-power has measurable improvements in my testing: ~10W → ~8W playing a 1080p vp9 in Firefox.
To be able to set EPP, the CPU governor also needs to be set to powersave. Further notes and data are available in that repo.
As PPD only sets platform_power and does not change EPP, its “power saving” mode is misleading. Setting platform_power to low-power alone did not have any measurable effect over baseline (stock kernel) in my testing.
I mean you can also set the scheduler on the kernel to default to powersave and then you can ignore doing this from userspace if you just want to trust performance hint calculations
