Thanks for the info! As long as hibernate works, I assume I’ll be fine. I probably misunderstood the previous posts as meaning that hibernate is not supported on Linux.
Loosing 6% per hour in s2idle would not work for me, as that means that a fully charged battery barely lasts from 5pm to 9am the next morning.
On a 55Wh battery that comes out to 3.3W, that’s pretty horrible, hell my t480s uses less idling with the screen on and that thing uses pretty old tech.
Hibernate is mostly software (store state to disk, load state from disk on boot), sleep needs more hardware support.
@Harrison_Asmar you might want to look into this, even if you aren’t using arch linux: Framework Laptop 13 - ArchWiki
Thanks for the pointer, that looks useful! I’ll keep the info around for when I get my laptop (batch 3 here).
I don’t have the 13" AMD (actually have a 16 for pre-order), but claims of 6% hourly battery life loss in standby make me suspect that the laptop might not be entering s0ix fully.
Intel has a S0ix self-test tool to check if their CPUs are entering s0ix. I remember running into a script that worked on AMD and required Secure Boot to be off on my previous Rembrandt-based ThinkPad, but I cannot find it anywhere. If anyone is able to find it, could anybody with the laptop run the test and report the results back?
All I can find is this, which is a good pointer, but I have not looked into it yet.
@Luca2 thanks for sharing! I’m not dealing with anywhere near that kind of power drain on s2idle with my amd 7040 framework 13, so I’m betting it’s either kernel config issue or some piece of hardware is causing the power drain and can be configured to be powered down in a dbus script or something similar.
Following up on my unscientific test before, I came across this -
https://community.frame.work/t/guide-linux-battery-life-tuning/6665/394
After removing TLP and re-enabling power-profile-daemon, I got 5% loss over a 7 hour period, which is much more reasonable.
Thanks for testing and reporting back here. This is very helpful!
Correct, for AMD only, you will want to use PPD.
PPD (power-profiles-daemon) (AMD ONLY)
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.
Are there instructions for disabling TLP and configuring power-profiles-daemon?
I see the recommendation for power-profiles-daemon for AMD in this Fedora article:
but no instructions for power-profiles-daemon use like there are for TLP
I’m on Ryzen 5 7640 and Fedora 39.
On a vanilla installation, TLP would need to be installed. So no, there is no instructions for disabling something that you would have needed to install.
If you have manually installed TLP, you would want to remove it and reboot.
As it comes installed as a default, you have your three power modes available from the pull down menu, performance, balanced and power save. Not much more to add unless you have a specific question I can answer about using those modes?
Could you maybe elaborate a bit what problems are expected when using tlp on an AMD Framework? I set up my machine with tlp, probably following an old/not yet updated guide, and I have not encountered any problems yet. TLP seems to have increased battery life for me, so I have kept it installed until now, but I would like to know what kind of errors could be caused by it.
Hi @Marvin ,
We are just seeing PPD to be more optimized for AMD Ryzen 7040 Series for now, no apparent errors for TLP/Ryzen in my short observation in the forums.
cheers!
Correct, and the biggest optimization is that PPD doesn’t interfere with suspend.
My contact at AMD expressed that TLP will likely interfere with proper suspend behavior.
Thank you both for the fast reply! I have not noticed any problems with suspend. Until now the laptop has stayed suspended and is losing less than 1% battery per hour when suspended. But I will keep my eyes open.
Sounds good 
Hey guys, I’ve been sticking with tlp and tuning it as I’ve gone, and since the bios update was released, I’ve been able to achieve a stable, low-draw config on battery.
If you want to run with this, be warned that I am running a minimal linux build that is not officially supported by framework. I’m running Xorg and i3wm, so your mileage will likely vary with a full-fat desktop environment, depending on the graphical processing draw. I’m also open to suggestions as to how to achieve more power savings.
I’ve gotten the s2idle sleep config working nicely here (well under 1% of draw per hour), but I have also configured hibernation (not via tlp) as well for longer periods of downtime.
Reminder for all reading this:
With this in mind, if you have hard data showing that TLP is outperforming PPD in Ubuntu LTS or Fedora, please feel free to share here as I’d be happy to share with AMD.
Hi All, as many others, I’ve been ecstatic to receive & setup my Ryzen Framework 13!
Currently running: Ubuntu 22.04.3 LTS
I’ve been interested in understanding the difference between acpi-cpufreq and amd-pstate specifically to optimize performance on AC and longevity on battery.
For the purpose of testing after reading more about the power-profiles-daemon, I disabled it and enabled TLP. Of note, after updating /etc/tlp.conf directly or via tlpui, it must be reloaded: $ sudo systemctl reload tlp
With this in mind, I started by comparing kernels. The current default kernel on the above OS is 6.2.0-36 which along with the suggested 6.1.0-1025-oem operate power management via acpi-cpufreq. This is hamstrung as it only offers 3 cpu freqs: 1.6, 2.2, 3.5 Ghz. One advantage it has is it will follow the min & max freq settings either provided via tlp or directly via /sys/devices/system/cpu/cpufreq/policy*/scaling_min_freq | scaling_max_freq (amd-pstate does not follow these from what I’ve seen).
Meanwhile, kernel 6.5.0-1007-oem enables amd-pstate by default. Details on either can be seen via: $ cpupower frequency-info (this required I install the linux-tools-common and respective kernel linux-tools pkgs, I also installed btop while I was at it).
Of note: amd-pstate opens up the the entire freq range, which shows on my system as 400Mhz - 4.8Ghz.
Another key feature, is this allows real-time switching between pstate methods. By default:
$ cat /sys/devices/system/cpu/amd_pstate/status
$ active
When set to active, there is an option to specify energy pref either via TLP or directly:
$ echo 'power' | sudo tee /sys/devices/system/cpu/cpufreq/policy*/energy_performance_preference
For more control, this can be changed to passive or guided. My testing thus far has been with the latter:
$ echo 'guided' | sudo tee /sys/devices/system/cpu/amd_pstate/status
This in turn, gives access to disabling AMD’s turbo core (this is accessible via TLP after the above status has been set):
$ echo 0 | sudo tee /sys/devices/system/cpu/cpufreq/boost
This reduces the max freq from 4.8Ghz to 3.5Ghz. From what I’ve seen, this means max draw goes from 28W to 18W.
Shout out to @topocount for the sample tlp.conf as I reviewed that as part of this testing.
Some metrics from this post:
a) started at 25% batt with an est 1 hr 40 mins @ 7.71W draw (per powertop, quickly settled down)
b) 1 hr later, at 15% batt with est 1 hr 15 mins @ 5.82W draw
Note: apps open include 2 firefox windows with 10 total tabs, 5 terminals (1 running powertop, another $ watch -n 2 /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
This indicates AMD power optimization still has some fine tuning to do. I’ll report back as I collect more observations.
Reading of interest:
AMD Pstate Kernel Doc
TLP Processor & other settings
I’ve been testing for sometime now and compiled my results here.
This led to publishing a power management guide as well.
Happy computing!