I attempted creating a custom Fedora image with the power saving techniques applied by default, you can see my original post linked below.
Totally agree with you though. Fundamentally for new users I think there needs to be a better out of box experience. System76, Slimbook, Tuxedo, and others have their own power management packages. I think it would be nice to have an official guide vs us cobbling things together after hours and hours of research that 90% of people would never do.
You really need a custom kernel with your Ublue images I think to make this really worthwhile
There are several patches which apply to the amd framework that are worthwhile.
Namely:
6.7-rc2 doesn’t include any of the above but DOES include power-supply fixups and amdgpu patches ; and is likely a good target to apply the above patches too (i’m using the fedora rawhide os-build as a starting point ; and have the above patches applied to my install).
Fedora kernel policy is NOT to include patches that have not already been accepted into the mainline kernel, and IMNSHO if you are going through the trouble of building an ostree image - shipping a custom kernel is a trifle to include.
OOTB apart from the PPD patch the userspace in FC39 is pretty spot on and there are not that many tweaks without the above out of distro/tree patches worth the effort of maintaining a specialized image for the fwamd specifically - sans kernel.
The two bits of hardware I am struggling with to find a working patchset are:
the USB-PD usci errors and ack bugs - this is still an issue and I’ve had instability with state changes around plug/unplug events leading to quite disturbing behavioiur with i.e upower reporting AC is present when it’s not and/or not triggering dbus on unplug to signal to PPD. This is AFAIC a kernel level/firmware bug with the PD controller interaction and should probably get a bit more attention from framework.
amdgpu issues with Memory management are still present for the phoenix platform, although potentially this might be fixable with a newer Framework BIOS patch for the AGPU.
And the last one is the Ambient light sensor - Can someone please let me know what model is in the amd framework? I’ve tried a number of out of tree patches for various ALS chips but I still can’t get the kernel to instantiate it correctly.
Custom kernels by their nature automatically exclude people who don’t want them. I know I will automatically write off an image with a custom kernel for a number of reasons, and i am very likely not the only person. Custom kernels are quite literally an individual preference, So if they feel like adding one in addition to a base image great, but as the default I would have to say no.
Well the reality is right now; there is no other viable option than out of tree patches .
IME running older kernels with out of tree patches is worse than running the current vanilla head with patches. But you are right this is a personal preference. I guess I just look at the huge ammount of resources required to build-pipeline a whole ostree image when all that really is needed is a simple ansible playbook to be run against a base install which is all that that is really needed for FC39.
packaging of ectool probably should go to fedora packaging for inclusion ; and the systemd device ID’s should hopefully make there way into updates in the normal packages given I think @linuxlion submitted them upstream.
Everything else current is dependent on out of tree or non-existent bits or in PPD’s case a non-accepted patchset.
@jwp Thanks for the clarifications.
I wouldn’t assume that everyone here knows how to do what you are referring to. I have never built my own kernel, and I would assume the vast majority here haven’t either, nor would they know how to install a patched PPD.
I was trying to look into setting up COPR repos, but have zero experience with that as well. It sounds like you may have the know how / experience. Would you want to create a COPR for the PPD / Kernel with relevant fixes applied?
A copr is a relatively good proposition. However a ublue ostree image is probably an easier way to distribute this and won’t require setting up i.e kernel signing keys/spec files etc; and whoever maintains the ostree image with custom kernel bits etc can do so much more easily.
Ideally the bits t hat can goes into upstream rawhide, and kernel bits will filter through eventually. But for today - given the OP has already started down an ostree style path - simply building on that is much simplier as it’s a matter of adding a tag to their existing image and pushing a whole delta of the osimage with the custom kernel/packages etc included.
There is already a framework ublue image (but currently for the intel only). And it would be simple to have a framework-amd13 split out with and without out of tree bits.
This would effectively be similar to other ublue images which include a heap of changes to base kernel/modules userspaces OOTB
i.e
Potentially if Framework wanted to start their own copr that might be a good supportable way forward.
It’s a Capella CM32183A3OP. Mine’s working out of the box with iio-sensor-proxy/GNOME 44.
It loads hid-sensor-hub (which isn’t conflicting with keyboard brightness keys unlike the 12th Gen) and appears as iio:device0 e.g.:
❯ cat /sys/bus/iio/devices/iio:device0/in_illuminance_raw
11
On the AMD FW? I am getting nothing appear
Can you copy the output of : udevadm info --export-db|grep -A5 -B2 iio
and dmesg |grep als
Please
This has been consistent fc38-fc39-rawhide and custom kernels based on those.
So if that is the chip it uses cm32181 module - which I indeed have compiled; modprobe cm32181 does not however net any change in behaviour:
modinfo cm32181
filename: /lib/modules/6.7.0-rc2+/kernel/drivers/iio/light/cm32181.ko
license: GPL
description: CM32181 ambient light sensor driver
author: Kevin Tsai <ktsai@capellamicro.com>
rhelversion: 9.99
alias: of:N*T*Ccapella,cm32181C*
alias: of:N*T*Ccapella,cm32181
alias: of:N*T*Ccapella,cm3218C*
alias: of:N*T*Ccapella,cm3218
alias: acpi*:CPLM3218:*
depends: industrialio
retpoline: Y
intree: Y
name: cm32181
vermagic: 6.7.0-rc2+ SMP preempt mod_unload
sig_id: PKCS#7
signer: Build time autogenerated kernel key
sig_key: 7A:E7:51:E6:BE:5F:E1:C5:54:22:20:3B:A2:94:54:C0:43:2B:ED:CF
sig_hashalgo: sha512
signature: 70:52:E7:C3:E5:43:C4:2F:97:6D:E5:FD:06:79:99:FD:C3:CD:B4:CB:
F7:15:DC:1B:51:96:B9:6C:9D:91:11:43:48:68:FE:4F:DC:4A:1A:8E:
4E:99:AF:95:1D:0E:22:7A:4B:F5:DC:4E:13:21:0B:3D:EB:69:1D:4F:
AF:81:3A:9D:EB:25:40:D5:00:D8:78:92:91:FD:37:54:68:66:A7:57:
58:18:6F:86:4D:13:D3:7C:3C:E8:84:7F:E4:FA:D7:31:0C:52:3C:83:
BC:5D:61:E7:64:64:89:53:4C:9B:F2:F8:0D:AE:B8:04:A7:5F:DC:76:
01:8A:11:E0:7D:18:11:4E:01:DD:9E:5A:B2:5F:95:3F:8C:31:F8:58:
BC:7E:A0:47:DA:85:55:40:43:2F:56:53:9E:CA:33:7A:97:3A:6E:22:
56:73:62:92:A2:A6:D9:DE:56:15:BD:5C:4E:BF:38:AE:9A:15:59:54:
65:F7:BC:B8:C6:3C:34:AB:6F:6E:54:A8:5C:E4:13:FD:09:7A:EC:42:
9D:DB:80:9B:7E:FE:C4:D4:DD:37:D9:26:1F:B8:BE:32:0A:79:31:07:
3C:0F:C6:13:D4:EC:FA:B3:12:F0:02:5A:D3:C4:7F:97:3C:AF:AF:88:
21:77:C0:09:AC:4A:F9:76:25:83:D3:C6:78:40:17:F4:F4:D8:80:95:
E8:2C:05:30:0D:98:9E:78:0F:CF:EC:12:53:F6:C3:CD:A4:10:23:98:
D5:B9:9C:55:7B:A7:C6:3F:2C:D3:CD:63:9E:C1:6D:76:1C:05:A1:A9:
99:C8:26:13:7A:3D:29:C8:E8:B1:54:46:F2:D9:62:E3:12:D9:A5:BF:
DC:F0:34:2E:49:B1:6C:87:36:EE:14:02:BC:3F:61:83:5A:81:FA:35:
D2:4B:C3:DC:E9:C4:17:E4:A5:51:B8:33:C0:56:99:DC:54:53:DC:E5:
66:10:61:CF:B6:F6:D4:D5:4C:AE:2E:9D:78:FF:90:C5:02:57:D2:C2:
AB:3C:8B:86:BF:74:56:C8:1A:18:54:99:17:65:6D:89:4C:08:ED:8D:
C2:36:00:24:A5:40:E3:3C:3C:C2:1A:60:C8:2F:B3:4F:EA:C1:AA:32:
BD:58:34:BF:9B:D5:21:96:02:65:52:48:9A:35:32:FE:44:36:0C:3D:
17:FF:B4:34:06:3B:C2:1E:B6:3C:61:33:F3:A8:18:87:B5:C5:0C:E7:
80:95:8B:64:64:60:B3:5E:31:4D:CF:D8:D9:38:D9:DD:0D:21:4F:BA:
D5:60:66:A2:33:91:2A:7E:CA:0C:09:E9:B8:1D:C3:05:2B:0F:2A:54:
27:BC:5E:D4:A1:C8:F3:0A:D3:61:9B:F5
If I manually unload the hid_sensor_als after modprobing the cm32181 I still get the same dmesg error I see on boot i.e:
[ 1872.851702] hid_sensor_als HID-SENSOR-200041.1.auto: failed to setup attributes
[ 1872.851711] hid_sensor_als: probe of HID-SENSOR-200041.1.auto failed with error -1
Can you also add the output of :
sudo /usr/libexec/iio-sensor-proxy -v -r
and
sudo iio_generic_buffer -A -N 0
Here.
For reference I get nothing - I had hoped this might have been some sort of magic init string I was missing but no.
** (iio-sensor-proxy:13116): DEBUG: 07:57:54.043: Starting iio-sensor-proxy version 3.5
(iio-sensor-proxy:13116): GLib-GIO-DEBUG: 07:57:54.045: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3)
** (iio-sensor-proxy:13116): DEBUG: 07:57:54.085: No sensors or missing kernel drivers for the sensors
root@emiemi:/var/lib/power-profiles-daemon# sudo iio_generic_buffer -A -N 0
iio device number being used is 0
Failed to read name of device 0
I did some power testing and have to say am a little bit disappointed when comparing it to my beat up t480s. Sure it performs a hell of a lot better and the bigger battery also makes up for some of it but it is kind of frustrating seeing something much newer struggling to even match the low load efficiency of the old one.
Test setup is the AMD 13, 7840U, 2x32GB Kingston 5600cl40, 2Tb 980 pro and an ax210 (3usb-c and one usb-a in the front left slot for expansion cards, removing the a made no visible difference). My previous I am comparing it to is a T480s, i5 8250u, 36GB(4+32), 256GB 970 evo, ax210, LTE modem, built in unifying receiver (that draws about 0.1-0.2W all the time) and a modded in 1440p panel. Both run a relatively light arch+sway install with tlp and the thinkpad is undervolted.
Tests are run with wifi connected (about 2m from the access point), bluetooth on but not connected, display at 20%, keyboard backlight off, webcam off(physical switch or complete delete), microphone off on the framework. All measurements are taken with powerstat after they settled for a bit.
I am using the format [TEST] [FW 13 value]/[T480s value]
Idle looks at least not worse but I think something with the hardware acceleration isn’t fully baked jet or something I can’t believe that a h264 decoder on a much newer node somehow actually needs more power than the old one, I hope this is fixable in software at some point.
AMD 7640U, yep.
❯ udevadm info --export-db| grep -A5 -B2 iio
E: ID_PATH_TAG=platform-AMDI0010_00-platform-HID-SENSOR-200041_1_auto
P: /devices/platform/AMDI0010:00/i2c-0/i2c-FRMW0005:00/0018:32AC:001B.0002/HID-SENSOR-200041.1.auto/iio:device0
M: iio:device0
R: 0
U: iio
T: iio_device
D: c 242:0
N: iio:device0
L: 0
E: DEVPATH=/devices/platform/AMDI0010:00/i2c-0/i2c-FRMW0005:00/0018:32AC:001B.0002/HID-SENSOR-200041.1.auto/iio:device0
E: SUBSYSTEM=iio
E: DEVNAME=/dev/iio:device0
E: DEVTYPE=iio_device
E: MAJOR=242
E: MINOR=0
E: USEC_INITIALIZED=7818269
E: PATH=/nix/store/vfvv6a7fi7arynggi9mig1wibnnz5wvf-udev-path/bin:/nix/store/vfvv6a7fi7arynggi9mig1wibnnz5wvf-udev-path/sbin
--
M: trigger0
R: 0
U: iio
E: DEVPATH=/devices/platform/AMDI0010:00/i2c-0/i2c-FRMW0005:00/0018:32AC:001B.0002/HID-SENSOR-200041.1.auto/trigger0
E: SUBSYSTEM=iio
E: USEC_INITIALIZED=7818217
E: PATH=/nix/store/vfvv6a7fi7arynggi9mig1wibnnz5wvf-udev-path/bin:/nix/store/vfvv6a7fi7arynggi9mig1wibnnz5wvf-udev-path/sbin
P: /devices/platform/AMDI0010:00/i2c-0/i2c-FRMW0005:00/0018:32AC:001B.0002/hidraw/hidraw1
M: hidraw1
~
❯ dmesg |grep als
~
❯ echo $?
1
One thing to remember is that you really need to compare total consumed power over time for a job run; especially when paired with the epp prefered cores patches (basically ‘good cores’ on zen dies are ones that can boost higher for lower power input) means you have cores boosting high and finishing jobs quickly and drawing less power.
3-4W idle seems pretty good considering that’s as low (or lower) than a recent ARM SBC like an rk3588 - which can’t get anywhere near the same performance states as the zen4.
Doing a timed kernel compile test run and watching power use and time for it is going to provide a better reference point than monitoring idle ‘hypermile’ use.
My main usecase for battery is ‘can I get through several site vists in 2hr blocks without needing to reach for a Power Plug’ which I think this configuration manages pretty well.
Would I like a couple more hours runtime, yes. But Hopefully at some point battery Cell replacement with a higher ah rating might become an option.
8 minutes of video played back with the power usage averaged over it is relatively equal to that no?
@tlvince is cm32181 loaded in your modules ? i.e lsmod |grep cm32181
and does the sensor disappear if you force-ably unload it?
I have the 7840U, I wouldn’t expect chip variations to make much difference but … from what I understand the iio/i2c bus is part of the webcam assembly; hardware button toggling the camera etc doesn’t seem to change anything for me - does the ALS disappear if you hardware toggle the webcam on your machine
i.e :[ 2180.543662] usb 3-1: USB disconnect, device number 2 [ 2182.593725] usb 3-1: new high-speed USB device number 3 using xhci_hcd [ 2182.748389] usb 3-1: New USB device found, idVendor=0bda, idProduct=5634, bcdDevice= 0.21 [ 2182.748403] usb 3-1: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [ 2182.748409] usb 3-1: Product: Laptop Camera [ 2182.748413] usb 3-1: Manufacturer: Generic [ 2182.748417] usb 3-1: SerialNumber: 200901010001 [ 2182.758202] usb 3-1: Found UVC 1.00 device Laptop Camera (0bda:5634)
The only other thing I can think of is do you have secureboot/TPM on or off in the bios. I’m running with it off
I am starting to think this is hardware issue:
Either:
a) The Assembly has bad/misconfigured solder points for the ALS sensor in my Unit or
b) They have substituted the Chip for a newer equivalent that is not as equivalent as they think.
Very keen to hear from other amd FW users wether they do or do not get the als populated in their sysfs
@Adrian_Joachim Not even a comparable/close test. Video playback is fraught with custom ASIC IP blocks and various optimizations. You need to test with compiling stuff that feeds the CPU - which is why kernel compilation is sort of the benchmark for this (phronix test suite has a kernel timed compilation test which is quick and easy to run up and monitor rapl power against).
One of the big advantages of PPD over TLP is that it can launch a job in performance boost states independent of the system set power .
i.e I can run
powerprofilesctl launch make bzImage
and it will run the job in a performance state without needing to tune global power bits. Super useful for i.e Steam etc ; and this is IIRC integrated with Gnome Out of the box (like run on dGPU is)
Well yeah and that looks quite unobtimized at this point.
I am not doubting the amazing performance per watt at heavier loads these awesome zen4 and rdna3 cores have but for battery optimization playing back a fullscreened video in kodi or a youtube video in firefox are pretty realistic use cases. It’s cool that I can compile the linux kernel for a third of the watt hours, that doesn’t really help when watching a movie and the hardware decoder decides it needs like double the power for it.
That does sound pretty neat but also like something I can easily live without, I can just shift tlp into ac mode while on battery if I actually want to do that.
Have created a thread/poll wrt ALS sensor here : [POLL] AMD FW 13 als/Illuminance sensor - present/populated
One interesting anecdote I found testing power consumption. I actually had ‘HIGHER’ iby a watt or so dle draw in airplane mode i.e with wireless disconnected than connected. BT does result in some drop in draw. I’m guessing that it’s to do with polling the interface and will retest after forceably unloading the wifi driver module . Because that was unexpected.