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 
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.
Thx!
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.
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.
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 
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).
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.
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
TLP_ENABLE=1
CPU_SCALING_GOVERNOR_ON_AC=schedutil
CPU_SCALING_GOVERNOR_ON_BAT=powersave
CPU_SCALING_MIN_FREQ_ON_AC=400000
CPU_SCALING_MAX_FREQ_ON_AC=5121000
CPU_SCALING_MIN_FREQ_ON_BAT=400000
CPU_SCALING_MAX_FREQ_ON_BAT=2200000
CPU_ENERGY_PERF_POLICY_ON_AC=balance_performance
CPU_ENERGY_PERF_POLICY_ON_BAT=power
RADEON_DPM_PERF_LEVEL_ON_AC=auto
RADEON_DPM_PERF_LEVEL_ON_BAT=auto
RADEON_POWER_PROFILE_ON_AC=auto
RADEON_POWER_PROFILE_ON_BAT=auto
USB_AUTOSUSPEND=1
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 
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
Hm, as mentioned in this thread, this script just runs every two seconds to set the power profile. Is there a reason to do it this way over using udev rules to change the profile on charger connect/disconnect, plus maybe some systemd units that set the profile on boot/wakeup? Does the file get periodically overwritten?
I guess it might help if you switch between lots of different userspace DE’s and tools. I’m running the patched PPD which is what works for me; so long as you’ve got ‘something’ hitting the hints
What branch are you using? Files · multi-drivers · Antoine Damhet / power-profiles-daemon · GitLab ?
