Message-ID: <a5353fe9-bcd2-4afe-97b5-76d61da8de49@kernel.org>
Date: Sun, 20 Apr 2025 10:03:28 -0500
From: Mario Limonciello <superm1@...nel.org>
To: Rong Zhang <i@...g.moe>
Cc: Kexy Biscuit <kexybiscuit@...c.io>, Mingcong Bai <jeffbai@...c.io>,
 Yemu Lu <prcups@...m.moe>, Xinhui Yang <cyan@...no.uk>,
 "Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>,
 linux-acpi@...r.kernel.org, Runhua He <hua@...c.io>,
 linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] ACPI: EC: Set ec_no_wakeup for MECHREVO Wujie 14XA
 (GX4HRXL)

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@...c.io>
>> Link: https://zhuanlan.zhihu.com/p/730538041
>> Tested-by: Yemu Lu <prcups@...m.moe>
>> Co-developed-by: Xinhui Yang <cyan@...no.uk>
>> Signed-off-by: Xinhui Yang <cyan@...no.uk>
>> Co-developed-by: Rong Zhang <i@...g.moe>
>> Signed-off-by: Rong Zhang <i@...g.moe>
>> Signed-off-by: Runhua He <hua@...c.io>
>> ---
>>   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"),
>> +		}
>> +	},
>>   	{ },
>>   };
>>   
> 

Powered by blists - more mailing lists