Hi Rong,
On 4/20/25 05:05, Rong Zhang wrote:
Hi Mario,
I noticed a patch [1] of yours fixed an identical issue on old AMD
platforms with outdated platform firmware while another recent patch
[2] set ec_no_wakeup for Lenovo Go S, and you are the author of amd-
debug-tools (hence also amd_s2idle.py). Could you kindly take a look at
this?
I reached Runhua in private, asking him to try disabling
/sys/kernel/irq/1/wakeup and
/sys/bus/serio/devices/serio0/power/wakeup to reproduce the effect of
patch [1]. Doing so also worked around the issue.
[1]: 8e60615e8932 ("platform/x86/amd: pmc: Disable IRQ1 wakeup for
RN/CZN")
Yeah; we concluded this is a bug in AMD platform firmware.
Similarly we have applied that same quirk for some BIOS versions of the
Framework 13 7040 model:
a55bdad5dfd1e ("platform/x86/amd/pmc: Disable keyboard wakeup on AMD
Framework 13")
f609e7b1b49e4 ("platform/x86/amd/pmc: Extend Framework 13 quirk to more
BIOSes")
In Framework's case this was fixed by their BIOS, so it only matches two
versions of their firmware.
[2]: b988685388ef ("ACPI: EC: Set ec_no_wakeup for Lenovo Go S")
In this case we found that the root cause for this issue is actually the
touchscreen. This was confirmed with an oscilloscope and by a hardware
modification.
Thanks,
Rong
Adding the platform into one quirk lists *might* be the right outcome,
but I would like to understand more about the failure first.
Would you please open a bug report on
https://gitlab.freedesktop.org/drm/amd/-/issues and attach the s2idle
report?
We can go back and forth there to decide.
Thanks,
On Fri, 2025-04-18 at 19:22 +0800, Runhua He wrote:
MECHREVO Wujie 14XA (GX4HRXL) wakes up immediately after s2idle entry.
This happens regardless of whether the laptop is plugged into AC power, or
whether any peripheral is plugged into the laptop.
Using `amd_s2idle.py --debug-ec', we found that the laptop has a wakeup
event triggered by IRQ 1 (PS/2 Controller) and IRQ 9 (ACPI SCI), and was
eventually woken up by IRQ 9. Taking a look at `dmesg', we found that the
EC was quite chatty after s2idle entry:
[ 1842.317151] PM: suspend-to-idle
[ 1842.317178] ACPI: EC: ACPI EC GPE status set
[ 1842.317184] ACPI: EC: IRQ (5)
[ 1842.317190] ACPI: EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0
[ 1842.317196] ACPI: EC: Polling enabled
[ 1842.317198] ACPI: EC: Command(QR_EC) submitted/blocked
[ 1842.317202] ACPI: EC: ACPI EC GPE dispatched
[ 1842.317248] ACPI: EC: Event started
[ 1842.317259] ACPI: EC: 2: Increase command
[ 1842.317264] ACPI: EC: Command(QR_EC) started
[ 1842.317271] ACPI: EC: TASK (14)
[ 1842.317288] ACPI: EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0
[ 1842.317294] ACPI: EC: EC_SC(W) = 0x84
[ 1842.317303] ACPI: EC: TASK (14)
[ 1842.317324] ACPI: EC: EC_SC(R) = 0x2a SCI_EVT=1 BURST=0 CMD=1 IBF=1 OBF=0
[ 1842.317329] ACPI: EC: TASK (14)
[ 1842.317336] ACPI: EC: EC_SC(R) = 0x2a SCI_EVT=1 BURST=0 CMD=1 IBF=1 OBF=0
[...]
[ 1842.317399] ACPI: EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0
[ 1842.317405] ACPI: EC: TASK (14)
[ 1842.317412] ACPI: EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0
[ 1842.317418] ACPI: EC: TASK (14)
[ 1842.317425] ACPI: EC: EC_SC(R) = 0x29 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=1
[ 1842.317432] ACPI: EC: EC_DATA(R) = 0x7b
[ 1842.317436] ACPI: EC: Command(QR_EC) unblocked
[ 1842.317445] ACPI: EC: Polling quirk
[ 1842.317448] ACPI: EC: TASK (14)
[ 1842.317455] ACPI: EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0
[ 1842.317463] ACPI: EC: Polling enabled
[ 1842.317466] ACPI: EC: Command(QR_EC) submitted/blocked
[ 1842.317469] ACPI: EC: Polling disabled
[ 1842.317472] ACPI: EC: Command(QR_EC) completed by hardware
[ 1842.317476] ACPI: EC: Command(QR_EC) stopped
[ 1842.317480] ACPI: EC: 1: Decrease command
[ 1842.317484] ACPI: EC: Query(0x7b) scheduled
[ 1842.317495] ACPI: EC: 2: Increase command
[ 1842.317499] ACPI: EC: Command(QR_EC) started
[ 1842.317504] ACPI: EC: TASK (14)
[ 1842.317516] ACPI: EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0
[ 1842.317521] ACPI: EC: EC_SC(W) = 0x84
[ 1842.317529] ACPI: EC: TASK (14)
[ 1842.317537] ACPI: EC: EC_SC(R) = 0x0a SCI_EVT=0 BURST=0 CMD=1 IBF=1 OBF=0
[ 1842.317543] ACPI: EC: TASK (14)
[ 1842.317550] ACPI: EC: EC_SC(R) = 0x0a SCI_EVT=0 BURST=0 CMD=1 IBF=1 OBF=0
[ 1842.317555] ACPI: EC: TASK (14)
[...]
[ 1842.317638] ACPI: EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0
[ 1842.317643] ACPI: EC: TASK (14)
[ 1842.317650] ACPI: EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0
[ 1842.317656] ACPI: EC: TASK (14)
[ 1842.317663] ACPI: EC: EC_SC(R) = 0x09 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=1
[ 1842.317670] ACPI: EC: EC_DATA(R) = 0x00
[ 1842.317674] ACPI: EC: Command(QR_EC) unblocked
[ 1842.317682] ACPI: EC: Polling quirk
[ 1842.317685] ACPI: EC: TASK (14)
[ 1842.317692] ACPI: EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0
[ 1842.317697] ACPI: EC: Polling disabled
[ 1842.317700] ACPI: EC: Command(QR_EC) completed by hardware
[ 1842.317704] ACPI: EC: Command(QR_EC) stopped
[ 1842.317707] ACPI: EC: 1: Decrease command
[ 1842.317711] ACPI: EC: Event stopped
[ 1842.317723] ACPI: EC: Query(0x7b) started
[ 1842.318142] ACPI: EC: Query(0x7b) stopped
[ 1842.318150] ACPI: EC: ACPI EC work flushed
[ 1842.318158] ACPI: PM: Rearming ACPI SCI for wakeup
[ 1842.318169] amd_pmc: SMU idlemask s0i3: 0x1ffb3ebd
[ 1842.318193] PM: Triggering wakeup from IRQ 9
[ 1842.318244] ACPI: EC: ACPI EC GPE status set
[ 1842.318249] ACPI: EC: IRQ (5)
[ 1842.318254] ACPI: EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0
[ 1842.318263] ACPI: PM: Rearming ACPI SCI for wakeup
I'm not quite sure what the EC was during this time. As
`acpi.ec_no_wakeup=1' works around this issue, I believe that the EC had
for some reason caused the system to wake up.
Browsing the source code, I found that in `drivers/acpi/ec.c',
`struct dmi_system_id acpi_ec_no_wakeup[]' records a few machines with
incorrect suspend behaviors caused by EC wakeup.
As this struct corresponds to a series of machines that needs
`acpi.ec_no_wakeup' enabled by default, add GX4HRXL to this struct. Note
that I have only matched the motherboard model, as MECHREVO is a "white
label" manufacturer using commonly used chassis and motherboards - GX4HRXL
may be found in a variety of laptops sold under different brands and model
names.
Since the reason behind this EC wakeup is not yet clear to me, I'm sending
this patch in hope of getting more comments and guidance on how to further
debug this issue.
Suggested-by: Mingcong Bai <jeffbai@xxxxxxx>
Link: https://zhuanlan.zhihu.com/p/730538041
Tested-by: Yemu Lu <prcups@xxxxxxxx>
Co-developed-by: Xinhui Yang <cyan@xxxxxxxx>
Signed-off-by: Xinhui Yang <cyan@xxxxxxxx>
Co-developed-by: Rong Zhang <i@xxxxxxxx>
Signed-off-by: Rong Zhang <i@xxxxxxxx>
Signed-off-by: Runhua He <hua@xxxxxxx>
---
drivers/acpi/ec.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 3c5f34892..19f1d36a5 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -2329,6 +2329,12 @@ static const struct dmi_system_id acpi_ec_no_wakeup[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "83Q3"),
}
},
+ {
+ /* MECHREVO Wujie 14 Series (GX4HRXL) */
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "GX4HRXL"),
+ }
+ },
{ },
};
