Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series
From: Basavaraj Natikar
Date: Fri Jun 19 2026 - 06:17:43 EST
On 6/18/2026 11:37 PM, Marco Scardovi wrote:
In data giovedì 18 giugno 2026 20:01:40 Ora legale dell’Europa centrale, Andy Shevchenko ha scritto:I also checked the BIOS 316 ACPI dump — the stalling path is byte‑for‑byte identical
On Thu, Jun 18, 2026 at 06:59:15PM +0200, Marco Scardovi wrote:Yes, it didn't solve the boot time problem
On Thu, Jun 18, 2026 at 16:35:37 CEST, Andy Shevchenko wrote:...
On Thu, Jun 18, 2026 at 06:46:28PM +0530, Basavaraj Natikar wrote:
On 6/18/2026 4:44 AM, Marco Scardovi wrote:
On Wed, Jun 17, 2026 at 10:33 PM, Armin Wolf wrote:
Have you tried it already?It seems I have much more to study about ACPI Tables. Sorry for the confusionI have extracted and decompiled the ACPI tables (DSDT and SSDTs) fromI traced the _EVT for pin 21 through the dumps:
acpidump. You can find the raw acpidump.out and the decompiled ASL
tables in the following Google Drive folder:
https://drive.google.com/drive/folders/1aTqLAnUhrTsPdpA8tfOFyRopG3P3DGnc
?usp=drive_link
As far as I can see/understand there is no _DSM method defined under the
GPIO controller device (AMDI0030) or the \_SB.GPIO scope.
Under the _AEI method (defined in SSDT9 line 188-193), pin 21 (0x15) and
pin 24 (0x18) are defined as:
GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullNone, 0x0000,
"\\_SB.GPIO", 0x00, ResourceConsumer, ,
)
{
0x0015 // Pin 21 (Touchpad attention line)
}
When triggered, they evaluate the _EVT method which calls:
Case (0x15)
{
\_SB.PCI0.SBRG.HNC0 (0x15, Zero)
}
Since Arg1 is Zero, HNC0 executes the Else branch, invoking M009 and
ATKM/ADTM, which stalls synchronously for ~36 seconds when executed
during the probe path at boot time.
_EVT(0x15) → \_SB.PCI0.SBRG.HNC0(0x15, Zero). With Arg1==0 it takes the
Else branch: M009(), then Notify(^^GPP0.PEGP, 0x81) "Information Change"
to the dGPU, then ATKM(0xC0)/ADTM().
and thank you for checking it out.
I'll do it. Let also me know for @Andy request below.So this _AEI event is dGPU/graphics‑related (it notifies PEGP), not the
touchpad — the earlier "touchpad" characterization is incorrect. The
touchpad (TPD0, _HID "ASUE1416", _CID "PNP0C50") has its own GpioInt() in
its _CRS on a different line (pin 0x08, Level/ActiveLow).
The ~36 s stall is consistent with these synchronous MMIO reads + dGPU
notify \running in the boot probe path while the GPU isn't ready
(no explicit Sleep in the path; a trace_method_name on HNC0/M049 would
confirm the exact blocking access).
Either way, running this AML synchronously at boot is the firmware issue
the no_edge_events_on_boot quirk works around.
Could you update the commit message accordingly — in particular, drop the
"touchpad" wording, since pin 21's _AEI event is the dGPU notify path, not
the touchpad?
Thanks for the details! The crucial and most important question here, is AMDIt seems ASUS released a new BIOS update 2 days ago specifically for my device.
going to push OEM(s) to fix firmware accordingly?
You can find the new acpidump here:
https://drive.google.com/drive/folders/1PYmF1R9n-6vHJVSH8bzEPZhRgdmBBJlT?usp=sharing
At least the DSDT has neither _AEI, nor ActiveBoth for anything (except speaker
device). Looks promising to me as a fixed version.
to 315, so the AML is unchanged and it'll still stall if pin 21 boots low.
On the OEM side, I'm connecting internally with our AMD contact for ASUS to report
this behavior and follow up on a firmware fix.
Thanks,
--
Basavaraj