[TRACKING] PPD v TLP for AMD Ryzen 7040


Would you mind opening a PR upstream systemd for it then? It seems reasonable to me if there are no negative impacts.

1 Like

It’s part of Info Centre not System Monitor - just poking around in gitlab to see if I can find the upstream of the kcm energy info module.

 18119 ?        Sl     0:00 /usr/bin/kinfocenter kcm_energyinfo

Looks like it’s probing org.freedesktop.UPower.Device: UPower Reference Manual via dbus to get the values.

Great, thx!

So on batt:
upower -i /org/freedesktop/UPower/devices/battery_BAT1

Out of curiosity, does Energy Centre show a constant rate when charging or does it appear to vary with load?

I wonder if it’s showing the charging rate rather than the system energy use?

I’ve also been taking a look at:

Screen shots in this thread ; [TRACKING] Suspend on linux drains a lot of battery compared to other laptop - #86 by jwp

Looks like it is reporting varying charging rate. Which I would assume is being controlled by the EC based on whatever programmed chemistry ideal for the cells.

Not at all! Would you mind testing this on your system before I make the PR?

Might as well double the sample size :sunglasses:

I don’t have a DP card but if you do, please test that as well.

First to determine which expansion port has the HDMI or DP:
grep -i hdmi /sys/bus/usb/devices/?-?/product

This should give a result such as:
/sys/bus/usb/devices/4-1/product:HDMI Expansion Card

Then enable autosuspend by substituting the above #-# into:
$ echo 'auto' | sudo tee /sys/bus/usb/devices/4-1/power/control

Personally, this is something I would probably add to /etc/rc.local, however I could see the benefit of including it in systemd if the application is wide enough.



Oh cool, thanks for those!

The only other item of interest from:
upower --dump

Appears to be:
$ upower -i /org/freedesktop/UPower/devices/DisplayDevice | grep energy-rate

It looks like this and BAT1 only refresh every 2 mins. I’ll have to dive deeper into their code to see how the KDE app is getting more meaningful data. In the meantime, powertop & powerstat are giving adequate insights for testing drain while on battery.

1 Like

Yeah it shows a very small drop in idle in power on the system I have as well. I have both DP and HDMI cards connected and it can apply to both.

Here’s the USB IDs for both cards for you to be able to add both to systemd.

32ac:0003 Framework DisplayPort Expansion Card
32ac:0002 Framework HDMI Expansion Card 

I’m a big advocate for optimal automatic defaults wherever possible. For example that’s why I changed amd-pstate to default to active in kernel 6.5 and why I’ve changed the default policy for USB controllers to use runtime PM in kernel 6.1.

The more things like this happen automatically the less that people need to use tribal knowledge to get the best power efficiency and consumption.


upower at least for me is reporting in near real time; where did you get the 2min from?

Brilliant, thank you for testing and confirming. I noted the HDMI id from dmesg and appreciate your inclusion of the DP id.

I’ve submitted a PR. Please feel free to review and advise with changes as needed:

Agreed for something like this where confirming community benefit can happen concisely.

My rc.local has long including things like calling a script to set MSR undervolting values, which need to be tested per system, since individual cpus have different tolerances.

Nice work with amd-pstate. It’s interesting to see how the cpu freq differs to balance-power vs power in active mode with system load.

Here’s to increased efficiency and reduced consumption!


I think you need to have the USB-ID as uppercase? At least that’s how it is for the other ones in the file.

Thanks @halemmerich!

Strange, since udevadm info output and usb specific entries in /usr/lib/udev/hwdb.d/ files are lowercase. Good to learn something new today :joy:

In the meantime, I’ve updated that file on my own system with the proposed change and the HDMI card does indeed boot up with autosuspend enabled.

Please see the updated: row from the below command indicating (XXXX seconds ago):
$ upower -i /org/freedesktop/UPower/devices/DisplayDevice | grep -e ener -e updat

When I ran watch on this, it seemed like the updates were around every 120s (at least whilst on battery).

1 Like

It looks like i can no longer edit my OP above.

Working yesterday, battery went from 68% - 28% over 3:59 on balance_power perf pref with pstate active, ppd set to power-saver, and hdmi autosuspend via udev. Hourly calcs matched total use at avg 5.52W.

Assuming linearity for the whole battery, this use case would allow 9:58 for a full batt. Or 90% use would give 8:58. My preference is to use 90-20%, so about 6:58.

With the Notebookcheck review as a baseline at 12:06 with 9.8% larger battery means parity with win11 will require finding about 0:57 longer runtime. Note: to verify need to confirm linux display settings for 150 nit brightness.

Another observation, the energy performance preference does not seem to be driven by PPD. That should either be tied in or added as a udev rule based on user preference. This is one place where TLP settings for this survives a reboot and switches based on ac or batt settings.

Now to switch back to TLP and test 4-6.

Config & methodology as outlined above.

  1. TLP, pstate status set to active, energy perf pref at power. Had to uncomment USB_AUTOSUSPEND=1 in /etc/tlp.conf for it to allow the HDMI expansion card to go into powersaving. 10% use took 66 mins, so 5.0W avg.

Based on the fact the hdmi card didn’t enable autosuspend until it was implicit in the conf file, these are active lines for the above testing:

$ grep "^[^#;]" /etc/tlp.conf 

This config does seem to allow normal suspend & resume.

Ran a longer suspend (over 4 hrs) and upon resume calculated rough max of
4d 13h (avg about 1/2W draw).


Yes, multiple actions isn’t yet supported by upstream PPD.

You can add https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/merge_requests/123 to your local build to add EPP support to PPD.

Thanks Mario, good to know.

At present I’ve a bash script to check/set these for testing. I would likely write a udev rule since that will be agnostic to these two approaches and will allow unlimited preferred settings tied directly to charging/discharging state.

Yeah I started down the dbus path ; then decided it’s better to just apply fix ppd directly.

Good to know, thx. If I stay with ppd, I may follow suit. That will depend on how the rest of this comparative testing goes :wink:

If you are a plasma user this is a simple as putting a sudo script into the dialog to fiddle on state change i.e:

@Mario_Limonciello I’ve created a bug for a workqueue stack dump that seems to be reliably reproducable on the amd gitlab instance : Stack Dump during Suspend - 7840U 6.7rc2 - kernel/workqueue.c:3400 __flush_work.isra.0+0x270/0x280 (#3008) · Issues · drm / amd · GitLab