Looks like its working on Debian sid fine. Thanks @Mario_Limonciello!!
2 Likes
I was able to replicate the results herodot got in Fedora 39, but on Arch. The 3.5W state occurred when KDE energy savings turned off the monitor. Normal use with a single browser tab, 25% screen brightness, and no keyboard backlight was closer to ~7.5W and idle (except Konsole, running powertop) with the screen on was ~5.2W.
I’ll also note that I wish I knew powertop required 133 minutes of measurement data to fully work (400 measurements at 20 seconds each) before starting this.
1 Like
Hi everyone thanks for the great work to get better power management on our framework.
Special thanks to @Mario_Limonciello for the ppa.
I have intalled Mario’s ppa on ubuntu 23.10 - and consumption is much better (between 7,5 and 5W).
Two questions here :
-
I get that ppd and amdpstate are now kind of “linked” thanks to the ppa. However can we get a better view on what is set by the ppd ? For instance : min/max fresquencies ? Turbo core on/off ? etc.
-
Since I’m not sure what the power profile allows and prevents exactly, it’s more an observation than a fact but it seems that after suspend eventhough I’m in “nergy saver” I get higher frequency than expected. After I reapply the profile (change it to another one then change it back), it seems fine.
Thanks !
1 Like
Thank you I just added it to my config
You can look at the PPD and Framework’s EC source code to see exactly what is changed. To summarize it, changing the slider will now:
- Set the EPP preference, which is a bias described here: amd-pstate CPU Performance Scaling Driver — The Linux Kernel documentation
- Set the CPUFreq scaling governor to either
powersaveorperformance. - Set the ACPI platform profile. This will use the
amd-pmfdriver to notify Framework’s EC to change CPU coefficients. The exact changes made are described here: EmbeddedController/zephyr/program/lotus/azalea/src/cpu_power.c at lotus-zephyr · FrameworkComputer/EmbeddedController · GitHub
This sure sounds like a kernel bug to me. Can you reproduce it on 6.7-rc7? If so; would you please file a kernel bugzilla with all the details from the command cpupower frequency-info before and after suspend?
NOTE: Unfortunately using this command is a little awkward on the Ubuntu mainline PPA, you might need to compile from scratch to get the tool.
7 Likes
I’ve installed the rpm on opensuse tumbleweed, and unfortunately while operating on battery I observe an annoying “mouse is attached to a rubber band” effect, which makes it slow to react until all of a sudden the cursor catches up.
I wonder if I’m an outliar. The benefit on power consumption is visible though.
I guess I’m gonna try this on my dual-boot F39 install.
EDIT: weirdly enough, no rubber band effect on F39. My F39 install is one kernel build behind tho, so I wonder if 6.6.7 on TW isn’t playing nice with the PPD patch while 6.6.6 I’m running on F39 is.
I’m updating my F39 install, I think I should get 6.6.7 once it’s done. Will report back.
EDIT2: I actually got 6.6.8 on Fedora, and it’s still working fine. So I guess that installing the patched PPD on opensuse wasn’t a good idea.
Truth is I would gladly switch to Fedora, but the lack of snapper out of the box is a deal breaker 
Can you please post a video of what you mean? I don’t expect that behavior at all.
If it’s a USB mouse it sounds like it’s configured for autosuspend and you should turn that off. This isn’t caused by PPD, maybe some other policy you did turned it on.
If it’s the touchpad or both can you please try to turn off PSR using the amdgpu debug parameter?
1 Like
Of course I don’t mind, thank you so much for doing this (was just about to do it but saw it in AUR 
)!
Cheers, it’s working great.
1 Like
Nevermind, upon some further testing I realized that even without your PPD patch, my touchpad is behaving erratically. I guess that some update in libinput or the kernel borked something for me.
Cool, yet another problem
It seems like 6.6.7 broke something for me.
I have gone back to UMA auto in the BIOS, removed the PPD patch, but nothing worked until I reverted to a snapshot from a few days ago, which runs 6.6.6 (I thank Tumbleweed’s snapshots OOTB every day!).
Not the topic of this conversation anyway…if I feel brave enough I may give the patch another try, but right now I’m just too happy to have my system back as it should, that I’d rather keep things as they are for a bit 
Gaming was terrible too, with constant lag and audio freezing. Dunno WTF happened but I guess I’ll stay on this kernel for a while.
Same values here, also on Arch + KDE (did not check the monitor off state), without any ill side-effects so far, thanks @efindus for the package!
After @Mario_Limonciello’s post about abmlevel, I included that in my testing with the following settings & results:
- PPD power-saver, amdpstate active, epp set to power, usb autosuspend enabled, camera & mic off. Apps firefox, libre office, 3-4 terminals under continuous use.
- 10% battery usage took 1:08 for an avg 4.85W
Seeking the holy grail, enabling powertop --auto-tune made little to no difference as:
- 10% battery usage took 1:07 at an avg 4.93W draw
Based on this latest and past testing detailed here, I’ve posted a power management guide.
Happy 2024!
3 Likes
Woof! I knew it took awhile but have always just kept working normally while powertop is taking measurements.
I’m also trying to figure out the best way to measure power usage here, and am I correct in saying that are only two sources (not counting things like an external power meter of course):
the battery charge level at (which of course only works when you’re not charging it:
/sys/class/power_supply/BAT1/charge_now
and the rapl interface at (it has the name package):
/sys/class/powercap/intel-rapl/intel-rapl:0/energy_uj
What does this second one actually measure? The entire APU’s energy usage? Or just the CPU part (somehow)?
Comparing the two values on my framework using this script (there’s some rounding errors due to the per-second polling):
I get about a 5W difference or so between the two values (e.g. rapl shows ~2W draw, battery shows it’s draining about 6.9W, this is at 6% brightness)
There’s also a second rapl device, intel-rapl:0:0 that has the name core, but that only reports really tiny amounts (in the 0.1w range)
Thank you for the support to our distro @efindus !
I also comment directly in the AUR package page because I had an error when I try to install it. Here the details:
Hunk #1 FAILED at 263.
Hunk #2 succeeded at 809 with fuzz 1 (offset 181 lines).
Hunk #3 succeeded at 854 with fuzz 1 (offset 173 lines).
Hunk #4 succeeded at 906 with fuzz 2 (offset 170 lines).
Hunk #5 succeeded at 946 with fuzz 1 (offset 169 lines).
Hunk #6 succeeded at 975 (offset 169 lines).
1 out of 6 hunks FAILED -- saving rejects to file tests/integration-test.py.rej
==> ERRORE: Si è verificato un errore in prepare().
L'operazione sta per essere interrotta...
-> errore durante la creazione: power-profiles-daemon-patched-amd-git-exit status 4
-> Installazione dei seguenti pacchetti non riuscita. È richiesto l'intervento manuale:
power-profiles-daemon-patched-amd-git - exit status 4
My system:
Host: Laptop 13 (AMD Ryzen 7040Series) A7
Kernel: 6.6.9-arch1-1
DE: Plasma 5.27.10
Any ideas? Thanks in advance.
Just delete the part patching the integration tests from the patch. You won’t need them when using the patch and they all conflict.
2 Likes
Confirmed, as this is what I did.
Don’t use an AUR helper, you’ll see which hunk failed. and remove the code from the patch files, 128/129
The problem is the code review was pedantic about changing whitespace when the existing code has problems and is consistent. So now there is a conflict depending on the way that they merge.
1 Like
Yeah, it can be a bit frustrating at times, but in this case for applying the patch locally, it works well enough to just delete that part of the diff. Looking very much forward to this being in an official release though, thanks a lot!
I’ve tried to resolve the conflict. I split off the common change to 130. So if you merge 130, 127, 128, then 129 I think it will work.