Regarding HDMI maybe you can try to turn off the corresponding USB port before suspend and re-enable it on wake up.
Some hints about disabling (“suspending”) USB ports :
And how to hook scripts to suspend/wake up (with systemd) :
https://wiki.archlinux.org/title/Power_management#Sleep_hooks
If turning off the USB ports during suspend helps, then is this something that the embedded controller firmware can do? You only need to keep those ports powered that have USB remote wakeup enabled (like a USB keyboard/mouse plugged in), and turn off ports connected to devices without remote wakeup (like the HDMI card, or a USB A card with nothing plugged in).
To those who is using linux mint (should also work on ubuntu), i have write a script which would automatically turn to deep-sleep when not plugged in and switch to s2idle when plugged in
please follow the the comment i made here: Ubuntu 18.04 - Dell XPS13 9370 no longer suspends on lid close - Ask Ubuntu
I retried testing power use during s2idle with an HDMI card plugged in, changing the “autosuspend” power options of the relevant USB port.
Tested in Fedora 35, Linux 5.16.9-200.fc35.x86_64
I changed the status on /sys/bus/usb/devices/[device]/power/control and autosuspend, checking that the system was suspended (or not) by checking runtime_status.
s2idle with HDMI card plugged in, runtime_status = suspended: 1.23 W
s2idle with HDMI card plugged in, runtime_status = active: 1.24 W
so I don’t think there’s actually a difference here. It does seem this is a bit of an improvement over the measurements I took with the 5.15.18-200 kernel.
I have opened a ticket to report the issue to Framework. Support told me they forwarded it to their engineering team. Let’s wait and see 
Quick update from framework:
We are working with our manufacturer and Intel on potential firmware changes that could improve the issue you’ve reported, but don’t have a specific timeline we can communicate at this time given the collaboration and work required.
Let’s wait and see
Hi everyone, jumping in with some weird but interesting numbers here. I run Ubuntu 22.04, read the couple posts about battery optimisation already, I installed powertop, tlp, etc… Every tunable is “good” in powertop, I get a decent 5-6w idle with the laptop running, and when sleeping (s2idle) I measure a consumption of just about 1w at the USB-C plug (using an USB-C power meter, while the battery is full). I let the laptop sleep for 3:30 hours, and the plug still reports about 1W consumption average (3.6Wh after 3h30min). This looks pretty good to me, it would mean the laptop can last about 55h in sleep which is fine. But unforunately, after I unpluged the laptop and resumed after 16h, the battery was almost empty, 48Wh had been consumed according to the power statistics, this averages at 3W compared the 1W I saw when plugged-in. Also the laptop was a bit warm. I’m very surprised by this? why would the laptop consume more power during sleep unplugged? maybe it was’t really sleeping and woke up when I unplugged it? I reproduce this problem twice already (the first time I didn’t measure). I’ll try to run more tests to see if I can help pinpoint the problem but if you have any clue on this difference: 1w when plugged-in, 3w when unplugged, I’m interested
It sounds like you’re comparing quantities measured through different means:
if I understand correctly, you measured the power draw while plugged in through an external power meter.
For unplugged, you based your power usage on a difference in charge as reported by the battery.
The two should be comparable, but since you’re using two different methods, the difference may come from at least one of the two methods not being properly calibrated.
Since the system is not suspended under s2idle at all, it quite conceivable that some glitch in the operating system ends up using more CPU when it is in “unplugged” mode than when it is “plugged in” – possibly just from extra activity from updating the battery charge somewhere. It would be silly, but quite possible.
Yes there can be a small offset but not this big, 3W basically means the laptop is running, and this drain speed is abnormal. This night I tried something slightly different: I unplugged the laptop first, and then put it to sleep (by closing the lid). This morning after 11h50min the battery reports only 9Wh drained, which means less than 1W average, so that means the sleep is working fine this time and with pretty good results. So I suspect unplugging the laptop during sleep is causing some trouble and higly increasing battery drain (maybe it’s waking it up or changing the power level somewhere). I’ll make a couple more tests to confirm this result so then we can investigate what happens when unplugging.
Ok so I made more tests, I can still reproduce the problem (not always but sometimes after 2-3 attempts). I tried checking dmesg to see if the laptop was changing state (leaving s2idle or something like that) but unfortunately no, when the high consumption sleep state is reached, nothing different appears in dmesg, I see the normal s2idle state on sleep and the resume line when I resume (also the power led is always pulsing as usual for a sleep state). Another thing I tried is to measure the consumption (at the outlet) when this happens. To achieve this I put the laptop to sleep but plugged in like before, which gets me about 1w consumption when all is well, then I try unplugging, wait a couple minutes, plug again, wait for the top up charge if any and then read the consumption. In the last try I made I got 1w at the first sleep, 1w after the unplug/replug, and the third time 7w !, the laptop is now sleeping (pulsing power LED) but warm and has a 7w consumption as opposed to the expected 1w. This is not the top-up charge because it’s been stable for hours, not decreasing any more. I did this test twice (resuming, make sure it’s fully charge, then sleep again and unplug/plug a couple times until I get something else than 1w and a warm laptop), and reroduced both times after just 2 or 3 unplugging. The LED on the side near the power plug is still blinking orange like when I put the laptop to sleep. Though when I unplug and replug as the battery is full the first time, it usually becomes white, it goes blinking orange when I wait a bit more and replug once the battery is no longer “full”.
I’m not sure what else I can do to debug this problem, I don’t have the HDMI apdater which is know to cause some issues, only 2 USB-C, 1 USB-A, and one microSD. Maybe I’ll try unplugging those but I don’t have much hope.
Edit: while the laptop was sleeping in this 7w consumption status (7.1w to be precise) I just tried hot-unplugging the microSD and USB-A ports, and noticed a drop of about 0.4w for the USB-A and 0.2w for the microSD (which means they do have a visible impact here although it’s not causing the whole extra 6w). After unplugging both I am down to 6.5w average. Unplugging the USB-C doesn’t have any impact because it’s passive I suppose. BUT THEN if I plug them back, I get +0.9w for the microSD and +0.4w for the USB-A, so now I’m up to 7.9w consumption now. Pretty weird an not consistent, I suppose the plugging/unplugging wake up some internal components which are now going to consume more?
For the record I tried doing this again when the sleep is working fine (1w) and got -0.05w for the microSD and -0.35w for the USB-A. Removing both I am down to 0.6w consumption in s2idle which is great actually, so a bit sad to learn that having an USB-A port is reducing sleep duration by 35% in my case. Plugging the USB-A back brings back the expected +0.35w and plugging back the microSD actually brings back +0.75w ! so I’m up to 1.75w now 
I’m sure this is tricky business to handle power state of all these devices espcially if you can hot-swap them during sleep, and honestly that is understandable to me I don’t care much if doing this is increasing the consumption. What I care though is the power consumption begin sometimes 1w and sometimes 7w without touching anything else than the power cord. Effectively making sleep unusable because you don’t know if it’s gonna drain your battery and heat up a lot in your bag.
Card consumption when idle (not sleeping):
Do you want to risk a BIOS upgrade to 3.08?
I updated already after I found this:
In my case, it works flawless.
Some people seem to still have issues with version 3.08.
( The link to the new BIOS version is the same as for 3.07, but with 8 instead of 7. )
@dma well it doesn’t seem likely to help considering what they said but for lack of better option or official response I’ll give it a try yes. I just installed 3.08 and I’ll run some sleep sessions and report if I see any change.
FYI 3.08 fixes drain while shut down, not during suspend.
I just found this news about a patch from Intel related to energy consumption in my RRS today
I have not been able to follow up on all the details, but I’m wondering if this might be related?
@feesh yes that’s why I said it doesn’t seem likely but thanks for adding this. And as expected, 3.08 did not help with this problem, I reproduce easily after just 1 unplug.
@dfh nice finding, it could be yes. We’ll have to wait and track in which kernel version this patch lands I suppose.
Yeah sadly I don’t have the time and setup to quickly test the patch. I hope someone can make sense of the change and if it impacts FrameWorks.
And hopefully be able to report back 
Small update after being in a situation where I’m actually relying on the battery quite a bit.
The nvme.noacpi=1 option indeed makes a huge difference.
With Fedora 35, Linux 5.17.4-200.fc35.x86_64
I’m now seeing:
s2idle with HDMI and USB-A inserted: 1W
s2idle with just USB-C cards inserted: 0.34W
“idle” use (reading something on the screen, with rather low screen brightness): about 4W
“screen locked” use (screen off): around 2W
So I’d say the nvme.noacpi=1 has almost completely resolved the power drain: even with 1W, the machine can stay suspended for more than 2 days and without the HDMI and USB-A cards it’s an entirely decent score.
A consequence is that the extra power use of these cards really sticks out as a sore thumb. It would be great if some kind of switch would be available to turn off the drain on these, even if it would require replugging them to make them functional again.
At the very least I think Framework should advertise that these expansion card can affect the power profile, even if they’re not used. It would have made me buy two extra USB-C cards so that I can place the machine in a power-frugal setup without having gaping holes in the bottom …
I have also seen the kernel in such a state that it was still using about 4W while suspended. I suspect that was due to a crashed R8153 ethernet adapter driver (that ethernet chip seems to be particularly mercurial with USB-C setups in linux; hopefully the workarounds improve a bit in the next couple of kernels). With that power use the laptop feels warm to the touch after spending some time in a laptop sleeve/bag. After rebooting this has not reoccurred, but it does provide a good motivation for monitoring the drain a bit.
That’s what I had to do as well. Using 4 usb-c cards, and can’t remember when I last swapped them out…because now, the USB-A and HDMI cards are just acting as dongles in my use cases…when/if I need to use them.
This makes the ‘swappable’ use case relatively more niche than before.
@Nils thanks for your update which confirms most of what I saw. I agree the impact on battery life should be at least specified on adapters.
What makes you point the R8153 ethernet adapter? did you find any way to poinpoint the reason for the incorrect suspended state? Also if that’s the same cause for me I don’t need to reboot, simply waking up the laptop and putting it back to sleep usually fixes the problem. Every time I put it to sleep I have to check the temperature 30 minutes after to be sure it’s actually sleeping correctly… Not very cool.
Only circumstance made me blame it. I did not do an analysis for the suspend states hit by the various components and I don’t have a real lead that a defunct R8153 driver was causing the problem. The R8153 did fail before with a
r8152 … …: Tx status -71
message and an “Oops” traceback afterwards. The Belkin Multimedia USB-C hub it is part of would not show the network interface afterwards anymore: not after uplugging and replugging and also not after suspending and waking (and various combinations of the two).
After that the laptop would get warm when suspended and put in a bag and showed ~4W power use (no peripherals other than the usual expansion cards inserted); consistently.
Both indicate that the kernel is in a bad state. So I made a leap and assumed the two are correlated.
Rebooting fixes the R8153 problems (until the next crash when in use) and fixes the bad suspend as well.
Oddly enough, I have a USB-C monitor that also has an R8153 network interface built-in and that one causes no problems. I’ve used the Belkin hub successfully with other (non-unix) devices, so it’s either the network that makes the hub act up or it’s the way it’s wired in the hub that is difficult for the linux driver (unlike most R8153 problem reports, the error occurs when the network interface is in use, so likely not due to power saving issues)