Just to add some data points for comparison:
Playback of the bunny video mentioned above is 7.5 to 8W using software- and 6 to 6.5W using hardware decoding. Intel i5 1240p, ~25% brightness, fedora 37, mpv.
1 Like
I think this is the right topic, but it appears that the AMD wifi card doesn’t work with suspend-then-hibernate (how are so few people using this functionality???):
Also of note is that if you run kernel lockdown mode (and you should), hibernate is disabled unless you use this patch: Enable hibernate during lockdown · GitHub
2 Likes
At least mention the fact that you wrote the patch, it has not been widely tested or dissemintated, and that you will now be running a tainted kernel.
Not sure myself if this is the right topic, but hey it ain’t completely wrong. As to why so few people use suspend or suspend-then-hibernate well I know for my part I would prefer to shut down in those instances for what are ultimately security reasons. A variety of attacks rely on the device already being powered on and in some form of operation, and yes I do have to concern myself with this to a degree so it is a reasonable precaution. Others likely don’t have these concerns and for them I can only speculate that it is the second reason I never use suspend or hibernate. I have been using linux exclusively for 14 years now, and at no time I remember has either operation worked flawlessly, or without a bunch of manual intervention. Even after it was working it woould break every couple of updates or everytime new processors got added to the kernel. It has to be one the most common “regressions” there is, and the fact that intel and amd both mess with sleep states on a regular basis does not help a bit. So it comes down to knowing what works most reliably for the least amount of effort i.e. this is a fiddly bit that has little intrinsic value outside of a perceived convenience. Back in the day when it took more than 10 seconds to boot I get it, but now the juice is just not worth the squeeze.
Same haha, though it is for Linux and can save battery life. My 2c: suspend-then-hibernate was quite involved with zero knowledge. It can be lot of work (1, 2, 3), and even after that, testing dependability and troubleshooting resumption issues were a pain. That’s with me being a bit lax-security wise (because I understand the implications).
However, since then, it’s been running flawlessly on 11th gen Intel for over a year (through multiple Fedora version upgrades) and (“miraculously”) still works on AMD. It’s been invaluable to me for saving battery as I have my system set to 1. automatically hibernate after suspending for 2 hours and also 2. hibernate at 7%. Therefore, I won’t lose more than 2 hours of battery life %tage on suspend, and shouldn’t ever lose the state I was working on. It also skirts the issue many people had with losing too much battery life overnight during sleep. Sidenote for just hibernation: it has proven immensely useful when I need to boot into another distro to use/test something but don’t want to lose my state, e.g. the rare Windows app. Or even just changing BIOS settings.
It seems there’s been a bump in demand for good UX here since it’s the year of desktop Linux (¿). I’m hoping the Fedora team can figure out how to in Workstation (or whatever distro) so that it can propagate throughout the ecosystem. It does require enough users to provide feedback and testing, so this is also my recommendation to the community try it out (with precaution)! Before, varying hardware configurations made it hard to have a troubleshooting critical mass, but it’s easier here since we run the same or similar hardware.
Maybe we should have a thread dedicated to hibernate/suspend-then-hibernate?
4 Likes
here are my results.
I. Trying to copy @Mistral24’s testing methodology.
My test setting was always:
1.) idle (20% Backlight; no running apps (except Konsole with powertop open); after 2 mins);
2.) light browsing (Firefox with 5 tabs of google searches open);
3.) writing a text in Libreoffice;
4.) watching Youtube Video (1080p; av1, speakers at 25%).
Wi-fi is on, Bluetooth is off.
AMD Ryzen 5 7640U.
I’m using Fedora 39 Beta & KDE Plasma with Kernel 6.5.8
PPD: 1.) 4-5W. 2.) 8-11W, 3.) 6-8W, 4.) 15-17W
TLP: 1) 4.3W. 2.) 6.5-8W. 3.) 4.9-5.7W. 4.) 11.6-12.7W
II. Trying to copy @Michael_Wu’s testing methodology.
5% brightness, AMD RZ616, 1TB Solidigim P44 Pro, 2x16GB Crucial 5600MT/s RAM).
1.) Idle
2.) Big Buck Bunny 1080P no HW decode (I skipped the HW decode test)
3.) Firefox YouTube 1080p AVI
PPD: 1.) 4-5W. 2.) 9-10W. 3) 15-16W.
TLP: 1.) 3.7-4W. 2.) 7W-8W. 3) 8.8-13W.
There is a very big difference in switching to TLP, and I haven’t even fully optimized it. The difference for me is especially noticeable in my actual day to day usage, which is more like a couple dozen tabs in Edge. I’ve slashed my power consumption by about 30-40%.
Thank you very much @Michael_Wu for the in-depth documentation (I might have stolen your TLP config 
)! I’m still having fairly high power consumption on Youtube, which is probably because of the freeworld drivers.
5 Likes
I experienced btrfs and kernel crashes with
nvme.noacpi=1
set on FC39 kernel ; I would advise that a disclaimer is added to the top post as this appears to be a dangerous combination with recent kernels and the AMD7040
4 Likes
I tried using power-profiles-daemon on a 7840u, but for some reason it seemed to limit igpu performance even on the performance mode. The igpu would not boost above 800 Mhz. Has anyone experienced this? I am running arch on the 6.6 kernel and 3.03 BIOS.
I have since switched to TLP and it the igpu boost behaves as expected with much better performance. I also think I am getting better battery performance with TLP, although I have not thoroughly tested.
Sure thing! That’s why I posted it and so that it can be used as a starting base for further discussion 
I’ve been using my AMD laptop off and on (but not much heavy use) the last week while traveling and battery life has been much better than my previous 11th gen mainboard (didn’t measure hard numbers though).
I saw the PPD v TLP for AMD Ryzen 7040 thread – has anyone tested Mario’s comment from there yet?
When I get the chance I will test, and probably better off responding in the respective thread.
I’ve had great success TLP + Ubuntu (Wayland/Gnome) on my Intel 13th gen framework, but one thing I’ve noticed is that when on battery, gestures with the touchpad to change workspaces are terribly slow. If I switch TLP off or switch to AC, they become smooth again. I’ve played around with the TLP config a bit and none of my modifications seem to address this particular issue; I assumed it would be graphics related, but perhaps not?
Note: when I switch workspaces using the arrow keys it is quite smooth! Also, when I switch off the PCIe Runtime PM on BAT it gets a teeny bit smoother. But not enough.
I followed the latest optimization settings exactly.
Fedora Rawhide, PPD, Plasma, Firefox with 5 Tabs, Screen @ 20% (with PPD dimming), Wifi Connected (AX Ap), BT Off idling under 4W:
Likely a Gnome issue, most likely, the animation is just too CPU intensive on a single thread (which TLP heavily affects).
I used to have this issue on Gnome, but haven’t experienced any lag on Hyprland.
1 Like
Thanks for the reply!
You’re conclusion seems likely, though I’m curious why it isn’t a problem when I change workspaces with the arrow keys?
I tried disabling animations completely, which seemed to help slightly. I’ll try to find a way to only disable animations for gestures.
Edit: I was unable to find a way to disable gestures animations exclusively.
1 Like
Looking towards the future:
I think we/framework should make a more dummy proof solution here.
Can we maybe brainstorm a bit?
For example; would it be possible to create a TLP configuration file and share that via an official “guide”?
At the moment, and in the near future, it will be very difficult for the medium-tech-savvy people to optimize their new laptop in linux.
AMD is a new platform; I expect (configuration) improvements to happen from time to
time.
And every bios release, people will find configuration improvements for battery optimization.
For all distro’s, every framework user probably benefits from the same configuration.
But not all of us have the time, or the hobby, to follow all the posts to stay up to date all the time.
What would be a good way to enable the whole community to stay as energy-efficient with their framework laptop as possible?
7 Likes
I attempted creating a custom Fedora image with the power saving techniques applied by default, you can see my original post linked below.
Totally agree with you though. Fundamentally for new users I think there needs to be a better out of box experience. System76, Slimbook, Tuxedo, and others have their own power management packages. I think it would be nice to have an official guide vs us cobbling things together after hours and hours of research that 90% of people would never do.
1 Like
You really need a custom kernel with your Ublue images I think to make this really worthwhile
There are several patches which apply to the amd framework that are worthwhile.
Namely:
- amd-pstate epp prefered cores
- rtc-cmos fixup
- cros_ec
- PPD epp preference switching support
- systemd tuning for auto power save for framework modules
- packaging for ectool to support the EC querying
6.7-rc2 doesn’t include any of the above but DOES include power-supply fixups and amdgpu patches ; and is likely a good target to apply the above patches too (i’m using the fedora rawhide os-build as a starting point ; and have the above patches applied to my install).
Fedora kernel policy is NOT to include patches that have not already been accepted into the mainline kernel, and IMNSHO if you are going through the trouble of building an ostree image - shipping a custom kernel is a trifle to include.
OOTB apart from the PPD patch the userspace in FC39 is pretty spot on and there are not that many tweaks without the above out of distro/tree patches worth the effort of maintaining a specialized image for the fwamd specifically - sans kernel.
The two bits of hardware I am struggling with to find a working patchset are:
the USB-PD usci errors and ack bugs - this is still an issue and I’ve had instability with state changes around plug/unplug events leading to quite disturbing behavioiur with i.e upower reporting AC is present when it’s not and/or not triggering dbus on unplug to signal to PPD. This is AFAIC a kernel level/firmware bug with the PD controller interaction and should probably get a bit more attention from framework.
amdgpu issues with Memory management are still present for the phoenix platform, although potentially this might be fixable with a newer Framework BIOS patch for the AGPU.
And the last one is the Ambient light sensor - Can someone please let me know what model is in the amd framework? I’ve tried a number of out of tree patches for various ALS chips but I still can’t get the kernel to instantiate it correctly.
5 Likes
Custom kernels by their nature automatically exclude people who don’t want them. I know I will automatically write off an image with a custom kernel for a number of reasons, and i am very likely not the only person. Custom kernels are quite literally an individual preference, So if they feel like adding one in addition to a base image great, but as the default I would have to say no.
1 Like
Well the reality is right now; there is no other viable option than out of tree patches .
IME running older kernels with out of tree patches is worse than running the current vanilla head with patches. But you are right this is a personal preference. I guess I just look at the huge ammount of resources required to build-pipeline a whole ostree image when all that really is needed is a simple ansible playbook to be run against a base install which is all that that is really needed for FC39.
packaging of ectool probably should go to fedora packaging for inclusion ; and the systemd device ID’s should hopefully make there way into updates in the normal packages given I think @linuxlion submitted them upstream.
Everything else current is dependent on out of tree or non-existent bits or in PPD’s case a non-accepted patchset.
@jwp Thanks for the clarifications.
I wouldn’t assume that everyone here knows how to do what you are referring to. I have never built my own kernel, and I would assume the vast majority here haven’t either, nor would they know how to install a patched PPD.
I was trying to look into setting up COPR repos, but have zero experience with that as well. It sounds like you may have the know how / experience. Would you want to create a COPR for the PPD / Kernel with relevant fixes applied?
1 Like
A copr is a relatively good proposition. However a ublue ostree image is probably an easier way to distribute this and won’t require setting up i.e kernel signing keys/spec files etc; and whoever maintains the ostree image with custom kernel bits etc can do so much more easily.
Ideally the bits t hat can goes into upstream rawhide, and kernel bits will filter through eventually. But for today - given the OP has already started down an ostree style path - simply building on that is much simplier as it’s a matter of adding a tag to their existing image and pushing a whole delta of the osimage with the custom kernel/packages etc included.
There is already a framework ublue image (but currently for the intel only). And it would be simple to have a framework-amd13 split out with and without out of tree bits.
This would effectively be similar to other ublue images which include a heap of changes to base kernel/modules userspaces OOTB
i.e
2 Likes