I’ve done the tweaks mentioned above, but I’m still having very bad standby life in Arch. In ~10 hours of standby, the battery dropped by 26%.
I’ve tried using powertop to analyze what happened, but to be honest I don’t understand a lot of the output (mainly pertaining to sleep data).
Anyone have any ideas? I’d appreciate any help, it’s the only thing I don’t like about the laptop atm. My battery life during use is perfectly fine.
Have you tried using s3 sleep instead of s0ix? It’ll take longer to wake but should get you better drain rates.
One other thought/question in general for folks seeing high standby drain on Linux:
@nrp Nope for me on both accounts. I’m only using USB-C and USB-A cards (see edit), and I’ve got the non-vPro version of the AX210.
I’m curious if it might be an issue with my kernel version. I ended up having to downgrade to 5.12.15, due to issues with bluetooth on the AX210 with any of the 5.13 kernels I’ve tried.
EDIT: I’m dumb. I swapped in an HDMI card late last night, to demo to a friend. I completely forgot to take it back out. That’s likely a large reason for my bad drain.
LOL, aren’t we all! 
Here’s hoping you get better performance overnight tonight!
I believe I have psr enabled, here is the output of “sudo cat /sys/kernel/debug/dri/0/i915_edp_psr_status”:
Sink support: yes [0x03]
PSR mode: PSR2 enabled
Source PSR ctl: enabled [0xc2044a16]
Source PSR status: SLEEP [0x30010136]
Busy frontbuffer bits: 0x00000000
Frame: PSR2 SU blocks:
0 1
1 173
2 173
3 173
4 173
5 0
6 173
7 173
PSR2 selective fetch: disabled
I still only see C0 and C1 having usage in powertop.
What’s your kernel version? I’m using 5.13 and am only seeing C8 states also, never reached C10. Apparently, we need 5.14 from @Michael_Wu testing. Seems a bit weird you’re seeing only C1 / C2 though. Something else must be missing?
In my testing, the microsd card also seems to have the same issue of power drain of 1W while not in use. Have not been able to get it to have lower-power draw yet, but I was playing around with so much stuff, maybe I missed something.
Anyone else noticing high battery usage from the device btusb? Mine shows that as the top power user during idle. One example point in time:
Power est. 3.21W 100% Device Radio device: btusb
And that’s with Bluetooth turned off in the GUI settings.
Any ideas?
Is that a powertop estimate? Powertop seems to guess randomly what’s using power. The only number actually reported by hardware is total power consumption. On multiple laptops I’ve had it report the wifi or bluetooth using dozens of watts.
Yes, that’s from Powertop, and it did look like at least 90% of the total at the time, so it must just be an artifact. Thanks!
For y’all that aren’t reaching C9/C10 and have PSR enabled:
topAs an example: I had a low battery alert styling in Waybar. At 15%, the color of a small rectangle in my tray would constantly transition linearly between red and white. That simple action constantly updated the display, preventing the CPU from reaching C9/C10 and causing increased idle power consumption.
Here’s some interesting info from Intel, for 11th Gen. Under 11th Generation Intel® Core™ Processor Family (for U-series, not Desktop) > Documents > Datasheet, Volume 1
Table 3-5: Some criteria to reach C9/C10:
Table 3-6: With up to a resolution of 5210x3200@60Hz, and PSR enabled, the CPU can reach C10.
Table 3-7: Seems like the USB4 controller plays a part in reaching C10 as well, so maybe check your USB devices. I can confirm my laptop reaches C10 with the HDMI Expansion Card plugged in, as well as in performance governor.
This has happened to me a few times 
Er, 5.14 is needed on Fedora to fix the PSR micro-stutter issue. PSR can still be enabled in the recent earlier kernels which allow reaching C9/C10 (can personally confirm).
Echoing this as well – ~2.6%/hr seems to be about what I’m getting on Fedora 34 which is much higher than it could be. I plan on using suspend-then-hibernate (similar to Windows) for better standby life. Some Linux hibernation info here, and the ongoing Windows discussion here, for comparison. Will report back once I dive into this!
From what I’ve gathered:
If this is S0 suspend (s2idle in /sys/power/mem_sleep), which should be S0ix on 11th Gen, being able to reach C10 plays a role in better standby battery life, so ensure that’s happening.
If this is S3 suspend (deep in /sys/power/mem_sleep), well, according to this System76 engineer:
It was discovered, deep in one of the Intel documents, that TigerLake-U no longer officially supported S3 suspend.
so maybe that’s why S3 suspend seems subpar, FWIW.
@TJ1 I’m also seeing the same draw with the microsd card 
It prevents the system from reaching PC 9 or 10 and costs over a full watt
I’m getting pretty subpar 8w performance on Manjaro +KDE
I can get it down to 5 watts if I unplug the microsd card, disable WiFi and Bluetooth, and log in to the virtual console (not plasma)
I’ve tried setting everything mentioned here and I’m not sure where the extra power draw is going. The CPU is spending most of its time in C9-10 and the GPU is idling.
Plasma has …something wrong with it as the CPU usage is always 1-2%. But even in the console mode it looks like I’m several watts higher than the expected base draw
Silly question - brightness set to minimum and keyboard backlight off? When I was first testing, the keyboard backlight got me. The fact it’s C9-C10 means all the power settings should be there, but maybe do powertop --auto-tune one more time with 2.14? Did you use rfkill to disable the wifi? And what’s your kernel version?
I’m hitting pc10 on Manjaro Gnome 21.1.2 but if I disable PSR (to fix the stuttering issue Periodic stuttering on fresh gnome.40 wayland install on Arch Linux - #6 by William_Light) the lowest I can get is pc8.
I can confirm default Manjaro Gnome installation gets pc10 for me as well (and better battery life than Windows with all its background processes). I thought I was going crazy due to the random stuttering, but I think I can live with it for a while until a battery-friendly fix is available.
Another item I have noticed… pcie aspm is supported:
[ 1.010937] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
But never changes from default normally:
cat /sys/module/pcie_aspm/parameters/policy
[default] performance powersave powersupersave
I’m not sure if thats because it’s adjusting, but not updating that or what… but if I set that to powersupersave it seems to allow cpu to get to lower states (C10, etc) here.
Unclear if it helps battery life yet.
Been messing with the power settings on my Framework for the past week and I figured I should post my own findings for others here. I’m running Fedora 34’s KDE/Plasma spin on it’s latest 5.13.15 kernel. I have messed with tuned, tlp, powertop and the power-profiles-daemon and ran with many of the configurations suggested on the various threads where it has been discussed.
Running with tuned or tlp alongside powertop I was definitely seeing an increase in battery-life, the cpu was routinely getting put into C7 states, but it wasn’t really enough. Usage typically wouldn’t fall below 6 watts. I was looking at anywhere from 5-7 hours of battery on a light workload (A few tabs of Firefox, Discord in the background, LibreOffice Writer.)
By far the best setup I have found is the power-profiles-daemon running alongside powertop. The power-saver profile gets the cpu into C10 states better than the other tools and I’m now looking at 4-6 hours for a heavy workload and anywhere from 8-12 on a lighter workload. At full idle, I have seen the laptop dip down to 3.2 watts of usage thanks to PSR.
SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/usr/bin/at -M -f /lib/udev/power-profiles/power-saver now"
SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/usr/bin/at -M -f /lib/udev/power-profiles/performance now"
The triggers run the shell scripts I made at /lib/udev/power-profiles. These shell scripts just run the “powerprofilesctl set” command for the profiles I want running in each power state. Running these comands through /usr/bin/at isn’t 100% necessary, but udev runs it’s triggers before a lot of modules are loaded at boot. Running your commands through at is a quick way to make sure your triggers are processed after more kernel modules are loaded.
TL:DR of this is that running these udev triggers through at allows this to work on system boot in addition to changing profiles whenever the system is plugged in or put on battery. I have the system set to performance on AC and power-saver on battery.