[TRACKING] Framework AMD Ryzen 7040 Series lid wakeup behavior feedback

Enzious · November 3, 2023, 3:18am

Alright, here’s the deal. I disabled the Lid Switch /sys/*/power/wakeup, but that didn’t do it. Me and a friend did some more testing and found out that when you close the lid, it sends two wake-ups, one from the Lid Switch and another is a wake-up from the keyboard! When you plug in the AC, it also sends a keyboard wake-up! I’ll post some udev rules soon to disable this soon!

dimitris · November 3, 2023, 3:20am

~~Isn’t that controlled by a BIOS setting on the 11 gen? On this 11 gen system for example (Fedora 38 with BIOS 3.17 and the that wake on AC option disabled), I’ve never seen this behavior.~~

Editing: I hadn’t used the power on when AC attached option and had mis-remembered what it does. It doesn’t apply to resuming.

Anyway, just for posterity, the steps below are the same, so resume-on-AC-attach does not appear to be a thing on 11th gen (and more recent comments below suggest it can be traced to AMD-specific EC source code anyway - so, misunderstanding corrected).

Just tested now:

Unplug charger (from the machine’s USB-C port)
Suspend (power button or lid close)
Plug charger in
Still suspended
Unplug, wait, plug in
Still suspended (when suspend was byby lid close, “verified” by observing WLAN reconnect on lid open, so timed consistent with laptop suspended throughout the lid closed time)

(Suspend is configured to s2idle on this machine)

dimitris · November 3, 2023, 3:33am

Just out of curiosity, what does /proc/acpi/wakeup look like on the AMD system?

FWIW I use this, run from a systemd unit, to disable wakeups from my external keyboard on a gen 11 system:

#!/usr/bin/bash

for device in `tail -n +2 /proc/acpi/wakeup |egrep -v 'PWRB|PXSX' |grep enabled |cut -f 1`; do
  echo "disabling $device"
  sh -c "echo $device > /proc/acpi/wakeup"
done

Enzious · November 3, 2023, 3:40am

Disabling everything in /proc/acpi/wakeup didn’t fix the lid issue but here’s the print out

> enzi@ultraportable: ~/projects/ec-patches  
$ cat /proc/acpi/wakeup 
Device  S-state   Status   Sysfs node
GPP0      S4    *disabled
GPP1      S4    *disabled
GPP2      S4    *disabled
GPP5      S4    *disabled
GPP6      S4    *enabled   pci:0000:00:02.2
GPP7      S4    *disabled
GP11      S4    *enabled   pci:0000:00:03.1
SWUS      S4    *disabled
GP12      S4    *enabled   pci:0000:00:04.1
SWUS      S4    *disabled
XHC0      S3    *enabled   pci:0000:c1:00.3
XHC1      S3    *enabled   pci:0000:c1:00.4
XHC2      S3    *enabled   pci:0000:c3:00.0
NHI0      S4    *enabled   pci:0000:c3:00.5
XHC3      S3    *enabled   pci:0000:c3:00.3
NHI1      S4    *enabled   pci:0000:c3:00.6
XHC4      S3    *enabled   pci:0000:c3:00.4

Kieran_Levin · November 3, 2023, 4:20am

One theory I have is that this code in the EC may be causing an additional interrupt to the host on wake:

github.com

FrameworkComputer/EmbeddedController/blob/lotus-zephyr/zephyr/program/lotus/azalea/src/power_sequence.c#L313


      
          
          
/*
           * Issue : 866a60d67
           * for this issue, if into S3 and resume back by keyboard, system would not wake
           * because scan code was send before espi_rst, at the moment system would not
           * take any scan code, co-work with BIOS when Keyboard event send,
           * do this workaround to send a scan code again
           */
          static void key_stuck_wa(void);
          DECLARE_DEFERRED(key_stuck_wa);
          static void key_stuck_wa(void)
          {
          	int wa_bit = *host_get_memmap(EC_CUSTOMIZED_MEMMAP_DISPLAY_ON);
          
          
	if (wa_bit) {
          		*host_get_memmap(EC_CUSTOMIZED_MEMMAP_DISPLAY_ON) = 0;
          		hook_call_deferred(&key_stuck_wa_data, -1);
          		simulate_keyboard(SCANCODE_UNASSIGNED, 1);
          		simulate_keyboard(SCANCODE_UNASSIGNED, 0);
          	} else
          		hook_call_deferred(&key_stuck_wa_data, 10 * MSEC);

When we go from S0i3 to S0ix, the EC will send some dummy key presses to the host so the keyboard will keep working. This may cause the host to wake up to screen on, and stay there.

Enzious · November 3, 2023, 4:31am

I think you’re right! I fixed most of my issues with the wakeups using the following rules that I put in the /dev/rules.d/ folder:

/etc/udev/rules.d/20-suspend-fixes.rules

ACTION=="add", SUBSYSTEM=="acpi", DRIVERS=="button", ATTRS{hid}=="PNP0C0D", ATTR{power/wakeup}="disabled"
ACTION=="add", SUBSYSTEM=="serio", DRIVERS=="atkbd", ATTR{power/wakeup}="disabled

The second line disables the keyboard from waking the PC, which fixes the lid waking the machine (along with the first line) AND the AC being plugged in (which sends a keyboard wakeup as well). You lose the keyboard wake-ups but the touchpad and everything else work fine.

I noticed you linked to your GitHub. ~~Is there a guide for consumers to customize and flash their own EC? I haven’t done the research yet.~~

RealKelsar · November 3, 2023, 8:42am

Seems like it kills lid open wake up too for me.

Enzious · November 3, 2023, 2:21pm

Try removing the first line and see if it disables wake-on-close but not wake-on-open.

dimitris · November 4, 2023, 5:54pm

Enzious:

/etc/udev/rules.d/20-suspend-fixes.rules

ACTION=="add", SUBSYSTEM=="acpi", DRIVERS=="button", ATTRS{hid}=="PNP0C0D", ATTR{power/wakeup}="disabled"
ACTION=="add", SUBSYSTEM=="serio", DRIVERS=="atkbd", ATTR{power/wakeup}="disabled

As an aside, how did you track down the particular identifiers to use for the rules? Especially PNP0C0D for the lid?

Nate_C · November 5, 2023, 5:30am

Is there anything like this that can be configured for Windows 11? I’m having an issue with my new laptop where it’s waking up from sleep on its own…

Enzious · November 6, 2023, 12:06am

sudo udevadm info -p -a /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:44/PNP0C09:00/PNP0C0D:00

I found the device by creating a script that tests disabling every result of:

find /sys -wholename "**/power/wakeup"

No clue.

Sharp_Hall · November 11, 2023, 5:38pm

Thank you for this! Using the second rule makes suspend work as expected on Debian Testing. That is, I can close the lid, automatically suspend, unplug and plug power without waking, then open the lid and have the machine wake.

I can also sleep from menu, close the lid and the machine will not wake, just from the second rule. It seems plug/unplug sending keycodes is the problem here.

ollien · November 13, 2023, 4:18am

No such luck here with those udev rules. Plugging in my power adapter still wakes the laptop

ollien · November 14, 2023, 3:35am

I missed something! There’s a missing quote at the end of the udev rule here and I totally didn’t catch it last night

The full rule is

ACTION=="add", SUBSYSTEM=="acpi", DRIVERS=="button", ATTRS{hid}=="PNP0C0D", ATTR{power/wakeup}="disabled"
ACTION=="add", SUBSYSTEM=="serio", DRIVERS=="atkbd", ATTR{power/wakeup}="disabled"

Gawdl3y · November 14, 2023, 9:01am

Echoing the success of others in this thread - adding the second udev rule listed above to disable waking by keyboard keeps the laptop from fully waking up from power plug/unplug. Is this function in the EC necessary for all systems, or is it just a workaround for a specific setup? I ask because I think that this side-effect (waking for power events unnecessarily) is undesirable and am curious if it may be properly fixable further down the line so that we don’t have to just disable waking by keyboard (not the end of the world, but I’d rather have it than not).

Johannes_Mueller · November 20, 2023, 7:31pm

I can confirm that @Enzious’ approach works

/etc/udev/rules.d/20-suspend-fixes.rules

ACTION=="add", SUBSYSTEM=="serio", DRIVERS=="atkbd", ATTR{power/wakeup}="disabled"

fixes the problem for me.

Thanks a lot.

halemmerich · November 20, 2023, 8:53pm

The second udev rule by @Enzious seems to be working around the wake up from plugging/unplugging power as well as waking up by closing the lid when already in standby for me.
udevadm control --reload-rules && udevadm trigger was seemingly not enough to apply it instantly, a reboot did the trick on Arch.

mailtodevnull · December 6, 2023, 6:21pm

If I may ask — has there been any movement on this fix landing upstream?

I am aware that there is a udev workaround, and a user workaround whereby I don’t suspend the laptop before closing the lid.

The problem for me is that I don’t trust my machines to do that. I’ve used linux for over 10 years, and I have a deep-seated mistrust of suspend just not working properly on lid close.

But I will try to overcome it

Mario_Limonciello · December 12, 2023, 3:17pm

I’ve sent this patch series to the mailing list to add a workaround in the kernel for the EC behavior (at least with BIOS 03.03). I would expect there is no need for a udev rule with this in place.

[PATCH 0/4] Add a workaround for Framework 13 spurious IRQ1 (kernel.org)

If you prefer the old behavior (which allows “real” wake from keyboard to work) and have this patch, there is a module parameter you can put on your kernel command line amd_pmc.disable_workarounds=1.

GFOM · December 15, 2023, 6:22pm

I received and installed my new AMD mainboard/RAM/Wificard, and lid closing going to suspend seemed to work fine until today I think. Fedora 39, might be the new kernel? Either way, not a huge deal to suspend then close the lid, but still.