[Guide] FW13 Ryzen Power Management

Hi All,

After about 2 months of active testing, this is a compendium based on my results and the insights of others here. Thanks everybody!

Recommended Steps
a) run PPD as advised by FW and set it as needed
b) Install & run a 6.5 or newer kernel, alternately enable amd_pstate via a kernel cmd
c) Install the fix from @Mario_Limonciello to reconnect PPD and amd-pstate (or courtesy of @efindus for the AUR)
d) Turn off the FW13’s physical switches for the camera & mic unless in use
e) Enable autosuspend of HDMI & DPI expansion cards if those are present
f) As desired, set abm level to decrease display power draw

Fedora already defaults to pipewire, for distributions that don’t, it may be worthwhile to migrate to it.

Likely Results
My observations were a reduction in avg draw on battery of 7W+ to < 5W for my std daily workloads. On my FW13 7640u with the 55W battery, this equates to an increase in runtime from ~8 hrs to over 11 hrs.


  • As noted elsewhere, video playback has a higher draw than it should. My testing showed less draw with hardware acceleration. Others report higher draw with HW accel. As driver & firmware optimisations continue, we should all expect this to reach parity with other OSes.
  • The Phoenix/Ryzen 4 architecture still has upstream optimisations in process or trickling down to the latest kernel builds. Which again leaves the opportunity for longer runtimes as this become part of distributions’ standard kernels.
  • The MediaTek mt7921 wifi driver also awaits optimisation as large downloads can draw impressively high power.

Not Needed

  • Initially, using powertop to calibrate and auto-tune seemed advisable. However after testing the above settings with and without auto-tune, there seems to be little advantage.
  • Likewise, my initial testing showed TLP reduced draw more than PPD. However, with the combination of settings above, this difference dissipated. YMMV.

Testing & Results
Methods and initial results.
Comparative results and summary.
Ambient Backlight Management Results.
Continued Observations Pointing Back to PPD.
Additional Details about USB Autosuspend.

As the Ryzen powered FW13 is my daily driver, I’ll update this post as long as it can be edited and post replies after that with new insights.


This is an awesome resource, thank you for putting it together!

1 Like

Thank you for the guide !

I have a question regarding bluetooth : when bluetooth is up but not connected, according to powertop it takes arroung 3Wh and awake 100% of the time. Did you investigate this part ?


Hi @inverse, glad to be of service!

Yes, my default is to turn off bluetooth when not in use. I take powertop’s readings with a grain of salt. To understand what something is really using, I’ll typically enable it for awhile (my test target has been 10% battery usage to smooth out fluctuations) then disable it for the same period. Then calculate and compare avg power draw. I’ve found the delta to be more accurate than the W usage reported in powertop.

If your use case includes keeping bluetooth enabled, you may wish to set the IdleTimeout to lower energy consumption when not in use.

Hope this helps!

1 Like

Hardware acceleration does help with higher resolutions and I do recommend keeping it on as software decoding only outperforms it below 1080p and even there not by much. The problem is just that the hardware decoder at this point uses way more power than it should (or does on windows) so video playback still makes quite a big difference.

I do hope this gets fixed soon.


Something else to consider, although its benefits are not vastly agreed upon, is disabling individual CPU cores if you don’t need them for your workflow.

I didn’t take proper measurements so far, but it really seems to have a positive impact on battery life at least on my system.

This can be done by echo-ing to a file for each CPU:

echo '0' | tee /sys/devices/system/cpu/cpuX/online

Where X is the number of the CPU core (starts at 1).

As doing that for each of them is cumbersome I made a CLI tool that helps with scaling to a given number of cores, if anyone is interested.

It really depends on the workload if this will have a good battery impact for the system or not. The APU generally performs most efficiently with all cores active. This is because of common IP for all cores that need to be lit up for any cores to be active.

For example if you have a multi-threaded task that nominally takes 30s when equally split across 4 cores and you take 2 cores offline that same will logically take ~45s.
Your outcome will be:

  1. The task taking 50% longer.
  2. The common blocks being active longer.
  3. The individual cores being inactive longer.

My hypothesis is that running a multi threaded workload you’ll not be any better off but if you’re running single threaded workloads across a bunch of cores you will be.

I think to really prove this out what you’ll want to do is come up with a few repeatable workloads that are representative that you can script and benchmark.

Also; if you haven’t already applied it you should consider applying the amd-pstate preferred core patch series. This will make sure that the scheduler is biased to the most efficient cores.


Really instructing thank you, indeed as I said that would need more thorough testing to really see if that makes a difference or not.

I’m not sure what patch you are referring to or how to apply it, I’m on kernel 6.6.10 if that’s relevant.

It’s not part of that kernel yet. This is the series.


You would need to manually apply until it’s landed upstream.


Oh I see, I’ll give it a try, thank you again!

Edit: Applied the patch, will start running in laptop mode with all the cores enabled, thx :slight_smile:

Have you tested PCI autosuspend (which is one of the things TLP and powertop’s auto tune does by default), to see how much it saves by leaving that on?

I have a PKGBUILD with this series here (as well as the ectool patch for the AMD, and one that enables hibernate while in lockdown mode).


Others can use modify this as they need to as well.

I don’t notice any difference in power usage, though, but with the nature of that patch, it’ll really depend on the silicon lottery.

In the first step it simply says

you will absolutely want to use power-profiles-daemon for the absolute best experience

but says nothing on how to do this?

This will depend on what distro you are using. Some distro’s will have it installed as standard, others you will be able to download it via that distro’s package manager.

Best guidance for this is to Google how to install PPD for your revelant distro and also check that if you are using PPD, that you uninstall TLP and/or any other power management tools.

1 Like

Thank you for a most useful guide.
And power-profiles-daemon 0.20 has been released that include’s SuperM1’s patches.

1 Like

I’m curious: do people set their ppd mode to power-saver on battery or leave it on balanced? I just noticed that it doesn’t switch by default (at least, not for me since I’m not using a DE).

Mine is pretty much always on power-saver (even on AC), but I don’t really run any intensive tasks.

Gnome will switch to power saver on low battery. That’s how I use it.

I have a script that switches to power saver when I disconnect from power supply, plus some wrappers around my build scripts that set performance on build, then drop back to power saver if on battery. I also leave libvirtd and associated bridges disabled by default, enabling them when needed, mostly during functional testing multiple VMs, then disabling them (though I think it doesn’t help once they’ve been activated?). All of this is probably, more-likely, most definitely overkill, but it’s what I do.