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!
3 Likes
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).
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.
- TLP, pstate status set to active, energy perf pref at power. Had to uncomment
USB_AUTOSUSPEND=1in/etc/tlp.conffor 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).
2 Likes
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 ?
Yup ; I just compiled and installed. I stared to make an rpm against the upstream fedora src and it became annoying because it’s tagged as a named version in the tarball vs numbered and I would have had to make a diff patch.
It’s based on the 0.13 in fedora anyway.
It looks like edits are only allowed for a few days, so pardon the new post.
Config & methodology as outlined above.
Test 4. synopsis above.
- 10% use took 0:57 for avg draw of 5.79W
Settings were:
TLP
amdpstate status = passive
energy_perf_pref = no longer available
scaling_govenor = conservative
scaling_max_freq = 2.2 Ghz
boost = off
tlp.conf min adjustments per above and with the following changes:
CPU_SCALING_GOVERNOR_ON_BAT=conservative
CPU_BOOST_ON_BAT=0
-
10% use took 0:51 for avg draw of 6.47W
TLP same conf with amdpstate status = guided -
after setting smt to off, no appreciable gains were observed. In fact, this could be deleterious as cpu load is spread over a smaller pool.
-
Reran some tests without
powertopand didn’t observe differences in run times.
Conclusions
- Running a newer kernel (such as 6.5.0-1007-oem from Ubuntu’s repos) includes AMD pstate. It is quite remarkable to see how each option manages power/performance. I found ‘active’ to provide the best of both. This can likely be activated on older kernels by updating their grub defaults.
- It’s worth enabling autosuspend for expansion cards. This seems to be functional via TLP, updated systemd rules or can be switched via /sys/bus/usb
- I’ll be running my FW13 via option 4 (TLP, amdpstate = active, energy perf pref = power or balance_power, scaling gov = powersave) to collect more data and fine tune further
To Do
- Please test via the same methods and share your findings
- Continue to share my own findings
- Post
tlp.confdiff with any add’l efficiencies - Switch back to PPD from time to time to re-evaluate
- Test
tunedas it develops - Look at how to undervolt the Ryzen 7040 series and evaluate viability & efficiency gains
In case the commands used during testing may be helpful to some folks:
a) current cpu power management config
cpupower frequency-info : as well as other options, see manpage. When amd pstate is active, this will include output of:
driver: amd-pstate-epp
b) check current amd_pstate status (if not found, amd pstate may not be active):
cat /sys/devices/system/cpu/amd_pstate/status
c) see which scaling governor is in use:
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
Note: changing policy0 to policy* will show all cpus/threads. For instance, to specify an alternate governor:
echo 'ondemand' | sudo tee /sys/devices/system/cpu/cpufreq/policy*/scaling_governor
d) see current energy performance preference setting:
cat /sys/devices/system/cpu/cpufreq/policy0/energy_performance_preference
e) see available energy performance options:
cat /sys/devices/system/cpu/cpufreq/policy0/energy_performance_available_preferences
f) review min/max cpu settings:
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_m*
g) review cpu frequency for all cores/threads:
watch -n 2 'cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq'
h) a couple options to see power draw on battery (as you’ll likely see, they don’t always agree):
sudo powertop -t 10
The first run takes awhile to build up enough data points to show results. Gives an idea of what hardware & processes are using energy. Can also tab through to other views/options. Flag is to update every 10 secs (instead of the default of 20)
or
sudo powerstat -R -c -z 10 1800
Gives W metrics while charging, flags are to start right away and give results every 10 seconds and take 1800 samples (ie: 5 hrs)
or
watch -n 10 'upower -i /org/freedesktop/UPower/devices/battery_BAT1 | grep -e ener -e updat -e perc'
On battery shows the discharge rate updated about every 2 mins, while charging “energy rate” may be the recharge rate?
or via the amdgpu driver stats:
sudo watch -n 10 'head -12 /sys/kernel/debug/dri/0/amdgpu_pm_info'
8 Likes
For the Laptop Zen3/4 SKU’s active is pretty much the only thing you would want. Guided is really for Desktop systems which lack EC with PMU tunings.
Active basically defers to the integrated provided firmware defaults ; which I assume are sanely tuned for setting the performance metrics. Guided basically tells the userspace/kerneland to make adjustment to the perf metrics just based on what kernel/userland is seeing and ignore the firmware/platform hints (if present).
1 Like
also there are some amd-pstate fixups sitting in patchwork due to a logic error which doesn’t set min/max freq limits which hopefully get pulled into the 6.7 final merge (they didn’t make it into the rc3 merge which closed last night).
That and the pref-cores patches which in theory should move single thread/boost workloads to the most efficent core… possibly will hep with Power.
2 Likes
Thanks @jwp, I appreciate your insights throughout!
My first post on this subject was in another thread and included links to:
AMD Pstate Kernel Doc
TLP Processor & other settings
as that’s where I began in prep for this testing.
Good to know about the pending fixups. I was going to comment on amd-pstate continuing to mature, however decided to present what can be done today from supported OS repos.