Suspend (s2idle) on mica, 2026-11-04

ADR 0009’s revisit trigger: one s2idle round trip per boot, from /init with gbook.suspend=1 on the command line (commits cf49174, c3fa7e7). The wake is the cros-ec-rtc alarm, 20 s after entry. Six cold boots, attempts 2026-11-04-5 to -10 (dumps/firstboot/attempts.tsv). Sources: the AP and EC SuzyQ console logs, and stock’s SYSTEM_LAST_KMSG (ramoops) via scripts/attempt.sh readback. Times are kernel uptime unless marked EC.

Result

Suspend works; resume resets the SoC every time. Entry, the device suspend and the wake all work. The resume dies in the PCIe noirq resume, and the EC then power-cycles the AP. No netlog arrives from these boots.

What the logs show

• The wake path works. In -5 the EC logged Handle sleep: 1 at EC 2359.68 s and the RTC host event (event set 0x02000000) at EC 2379.80 s, 20.1 s later. Then AP_RST_L transitions not expected came 0.76 s later (-8: 0.70 s), and MKBP: The AP is failing to respond. The EC ran a host reboot (Reset cause: hard), and the firmware fell through to stock.
• The PCIe GDSCs. At a804c57, gcc-x1e80100.c gives the PCIe GDSCs PWRSTS_OFF_ON, so gdsc_disable() really switches them off at suspend (gdsc.c:369-380). On resume they stayed off (-6, -7). sc8280xp’s PCIe GDSCs use PWRSTS_RET_ON, which leaves them on and lets the hardware retain them.
  • Upstream: “clk: qcom: gcc-x1e80100: Do not turn off PCIe GDSCs during gdsc_disable()”, Krishna Chaitanya Chundru (Qualcomm), patch 6/7 of a series, LKML 2026-01-02, https://lkml.rescloud.iu.edu/2601.0/00459.html, Reviewed-by Bryan O’Donoghue. It is not in a804c57.
  • It is now local patch kernel/patches/0008 (ADR 0007). With it, the GDSC warnings are gone (-8, -9, -10).
• The resume still dies in the PCIe controllers. With PM_SLEEP_DEBUG (kernel/mica-pmdebug.config) and pm_print_times:
  • -9: PCIe 6a’s controller resumed (genpd_resume_noirq 526 µs) and so did its root port. The NVMe endpoint’s pci_pm_resume_noirq then never returned, while other devices went on resuming for about 100 ms.
  • -10: with 6a disabled, PCIe 4’s own controller resume (qcom-pcie 1c08000) never returned.
  • In both boots, PCIe 4’s genpd_suspend_noirq took 3.07-3.29 s on the way in.
  • Ramoops ends on the same line as the console (-6, -9), so the reset leaves nothing more.
• Two different failures (pm_print_times timing and the source). qcom_pcie_suspend_noirq() (pcie-qcom.c:2340 at a804c57) calls dw_pcie_suspend_noirq() (pcie-designware-host.c:1225). That either sends PME_Turn_Off, waits for L2 (polled in 1 ms steps) and shuts the host down, or returns at once and keeps the link, depending on pci_host_common_d3cold_possible() (pci-host-common.c:269-325).
  • PCIe 6a kept its link. Its genpd_suspend_noirq took 167 µs (-9) and its resume 526 µs: too short for either the L2 wait or a host re-init with link training. So the NVMe endpoint’s config access went over a link that was never shut down, and still hung.
  • PCIe 4 shut its link down. Its genpd_suspend_noirq took 3.07-3.29 s (unexplained: the L2 poll times out at 10 ms), and on resume its host re-init (qcom_pcie_resume_noirq, pcie-qcom.c:2398) never returned.
  • A lead, unverified. Patch 0008 and the upstream series change only the gcc_pcie_N_gdsc entries. The PCIe PHY GDSCs (gcc_pcie_3/4/5/6_phy_gdsc) are still PWRSTS_OFF_ON (gcc-x1e80100.c:6595-6663), and pcie6a_phy has power-domains = <&gcc GCC_PCIE_6_PHY_GDSC> (hamoa.dtsi:3546). So genpd collapses the PHY’s domain at suspend. The USB PHY GDSCs in the same file are already PWRSTS_RET_ON (gcc-x1e80100.c:6775-6867). Upstream changed those because “the QMP combo PHYs lose their configuration on machine suspend” (“clk: qcom: gcc-x1e80100: Fix USB 0 and 1 PHY GDSC pwrsts flags”, patchwork comment 25978987). A PCIe PHY that lost its configuration would explain a dead link on 6a. That is an inference; the next boot can test it.
  • Inference, not verified: an access to a PCIe block that is not powered, or behind a dead link, hangs the bus. On Qualcomm that ends in a reset with no kernel message.
• Other observations.
  • The touchscreen bus times out on the way into suspend in every boot (geni_i2c a80000.i2c: Timeout cancel_m_cmd); this is the parked touchscreen fault and not fatal.
  • mem_sleep offers s2idle [deep], so PSCI SYSTEM_SUSPEND is available too (inference from the kernel listing “deep”). It is untested.
  • SCMI was clean on every boot (0.1 ms).
  • Idle power stays unmeasured: on the bench the SuzyQ powers the Googlebook, so the battery’s current is charge current.

Open, for the owner

1. Test the PHY GDSC lead: a local patch moving the four gcc_pcie_N_phy_gdsc to PWRSTS_RET_ON, then one boot. No upstream patch for it was found tonight.
2. Find the hanging step in PCIe 4’s re-init: dyndbg for pcie-qcom.c and pcie-designware-host.c on one suspend boot.
3. Try deep (mem_sleep=deep). It takes a different firmware path, and qcom_pcie then keeps the CPU-PCIe interconnect up (pcie-qcom.c:2385).
4. Keep ADR 0009 as it is. Suspend fails before any idle state matters, so cpuidle is not the blocker yet (inference).

Update: the first complete round trip, with patch 0009 (2026-11-04, 5:01 AM ET)

Attempt 2026-11-04-11: kernel #24 with patch 0008 and local patch 0009, which moves the four gcc_pcie_N_phy_gdsc to PWRSTS_RET_ON. Board DTS, both PCIe links on. The resume completed. Source: netlog 2026-11-04-netlog.txt#6.

• Timing:
  • PM: suspend entry (s2idle) at 120.03 s;
  • suspend-to-idle from 126.24 s to 140.70 s (the RTC alarm);
  • noirq resume 883 ms, early resume 594 ms, resume 4855 ms (much of it console output from pm_print_times);
  • PM: suspend exit at 147.72 s.
• Counters: rc=0. /sys/power/suspend_stats: success=1, every failure counter 0.
• After the resume:
  • cpufreq: 3 policies, with 0 SCMI timeouts since the suspend.
  • Wi-Fi relinked in 8 s, same address, now on 5720 MHz (earlier boots joined on 6 GHz).
  • /init ran to GBOOK: end and sent the netlog.
• Still to look at:
  • PCIe 4’s genpd_suspend_noirq still takes 3.28 s.
  • ath12k’s pci_pm_resume_early takes 0.54 s.
  • At 142.17 s qrtr logs failed to announce new service / failed while handling packet from 7:-2.
  • suspend-wakeup is empty: no wakeup source counted the wake, although the EC logs the RTC event.
• What fixed it (inference): retaining the PCIe PHY GDSCs is what changed between -9/-10 and -11.
  • It fits the lead above: a collapsed QMP PCIe PHY loses its configuration, which explains both 6a’s dead kept link and PCIe 4’s hung re-init.
  • One boot proves only that it can work. Repeat boots show whether it is reliable.
• Console boot #11 booted -10’s image again after -10’s reset, before -11 was written. It reset the same way after the resume (143.47 s), and is recorded with -10.
• Idle and suspend power stay unmeasured. On the bench the battery reports charging: power_now -2.96 W before and -2.49 W after, sign convention not checked.

Update: 3 of 3 with patch 0009 (2026-11-04, 5:13 AM ET)

Two repeat cold boots of -11’s image (kernel #24, board DTS) were added to -11’s row with attempt.sh add-boots (netlogs 2026-11-04-netlog.txt#7 and #8). Both completed the round trip, the same as -11:

So with 0008 and 0009 the round trip is 3 of 3 cold boots, against 0 of 7 before (-5 to -10 and console boot #11). Power is still unmeasured.

Update: the -11 loose ends, read from the netlogs (2026-11-04, 5:20 AM ET)

Read offline from 2026-11-04-netlog.txt#6 to #8 and the source at a804c57. No new boots.

• PCIe 4’s 3.1-3.3 s genpd_suspend_noirq is silent. No kernel line falls between its calling and returned lines, and there is no Timeout waiting for L2 entry! warning, so the 10 ms L2 poll (pcie-designware-host.c:1255-1268) did not time out.
  • What runs after the poll: dw_pcie_stop_link(), then qcom_pcie_host_deinit() (pcie-qcom.c:1453-1470). That asserts PERST, powers the WCN7850 off through pwrctrl (pci_pwrctrl_power_off_devices), powers the PHY off and runs the SoC-specific deinit.
  • The WCN power sequencer has only millisecond delays (pwrseq-qcom-wcn.c:146-149, 234-249). Which step takes 3 s is not known.
  • Next: one suspend boot with dyndbg for pcie-qcom.c, pci-pwrctrl* and pwrseq-qcom-wcn.c. It costs about 3 s of entry time only, so it is not urgent.
• ath12k’s 0.54 s pci_pm_resume_early is the WCN7850 booting again. pwrctrl powered the chip off at suspend (above), so on resume MHI powers it on (mhi mhi0: Requested to power ON at 141.67 s, Wait for device to enter SBL or Mission mode). ath12k then logs the chip and firmware again (142.20 s). That is expected with pwrctrl power-off (inference).
• The qrtr line is resume-only. failed to announce new service / failed while handling packet from 7:-2 appears once in each resume boot (netlog #6, #7, #8) and in none of the five boots without suspend (#1 to #5). It comes at 142.17 s, while the WCN firmware is coming back over MHI. It is net/qrtr/ns.c:490-493: the name service could not broadcast a new server announcement (ctrl_cmd_new_server). Wi-Fi relinked in 8 s each time, so it looks harmless (inference).