Subrata Banik has posted comments on this change by Nick Vaccaro. ( https://review.coreboot.org/c/coreboot/+/83932?usp=email )
Change subject: mb/goog/brya: Don't lock GPP_F15 (FPMCU_INT_L) ......................................................................
Patch Set 5:
(1 comment)
Patchset:
PS3:
GPE status just before handing control off to libpayload (just before returning from bs_write_table() ):
[DEBUG] GPE0 STD STS: eSPI
Here is my observation:
1. Locking a PAD configured as GPE is the reason for the auto boot after system enter into S5. 2. I have dumped the GPE status before issuing poweroff from depthcharge screen.
``` Exiting depthcharge with code 2 at timestamp: 21490780 Powering off... GPE0_STS_31_0 = 0 GPE0_STS_63_32 = 20804 GPE0_STS_95_64 = 64000 <----- GPP_F14 GPE Status is set (GPE0_STS[127:96] = 4000 GPE0_EN_31_0 = 0 GPE0_EN_63_32 = 0 GPE0_EN_95_64 = 4000 <----- GPP_F14 GPE Enable is set (GPE0_EN[127:96] = 0 ```
GPE 78 aka GPP_F14 (touchpad) has GPE configured as GPE Enable and at the same time GPE status for this PAD is also set. Resulted in a auto wake after I issued poweroff at dev screen.
While waking the device from S5->S0, due to lack of XHCI W/A present into the mainline, I have experienced bunch of PMC IPC errors and eventually device booted to OS, where I can see GPE 78 as wake source (as guessed from the above log).
``` 10 | 2024-08-15 14:25:56-0700 | ACPI Wake | S5 11 | 2024-08-15 14:25:56-0700 | Wake Source | GPE # | 78 <---- this is GPP_F14 12 | 2024-08-15 14:25:56-0700 | Firmware vboot info | boot_mode=Developer | fw_tried=A | fw_try_count=0 | fw_prev_tried=A | fw_prev_result=Unknown ```
3. Resolution: aviod configurating the lock for GPE so, that we are able to clear the GPE status in order to avoid fake wake.