PCI: mediatek-gen3: MT8189 never wakes from s2idle with ASPM L1.2 enabled

PCI: mediatek-gen3: MT8189 never wakes from s2idle with ASPM L1.2 enabled

[zoan37]

Hi Ryder, Jianjun,

I'm running mainline on an MT8189 Chromebook (Lenovo IdeaPad Slim 3
Chromebook, board "quigon" in the skywalker family, with an MT7922
Wi-Fi card, 14c3:0616, on the PCIe port). When ASPM L1.2 is enabled on
that link, s2idle hangs every time. My question: on MT8189, does
L1.2 across SPM sleep need anything beyond what pcie-mediatek-gen3
does now?

Setup

- next-20261008, plus the posted Genio 520/720-EVK series (which adds
  mt8189.dtsi, from Louis-Alexis Eyraud), plus the board DT. The PCIe
  node is the one in that mt8189.dtsi ("mediatek,mt8189-pcie",
  "mediatek,mt8192-pcie"). It is the same as ChromeOS's node except
  for the clock list. Pins: GPIO48 WAKEN, GPIO49 PERSTN, GPIO50
  CLKREQN. The board overrides the T-PHY to generic-tphy-v2, as
  ChromeOS has it; v3 froze the SoC at link-up.
- System sleep: the firmware has no PSCI SYSTEM_SUSPEND. As in
  ChromeOS's DT, s2idle uses an idle state with PSCI CPU_SUSPEND
  0x020180ff (min-residency 0xffffffff). When the last CPU enters it,
  TF-A and the SPM put the SoC to sleep.
- mtk_pcie_suspend_noirq() returns early when
  pm_suspend_default_s2idle(), as in ChromeOS's driver. The bridge
  stays in D0 with its power and clocks on, and the link is left to
  ASPM.
- From ChromeOS's mtk_pcie_startup_port() I added
  PCIE_LOW_POWER_CTRL_REG (0x194) BIT(8), which force-disables L0s,
  and PCIE_AXI_IF_CTRL_REG (0x1a8) BIT(12), the AXI0 slave error mask.
  PCIE_DISABLE_DVFSRC_VLT_REQ is set, as upstream already does.

Symptom

With pcie_aspm.policy=powersupersave, both ends get L1.1 and L1.2
(ASPM and PCI-PM) enabled:

  00:00.0 L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+
                     T_CommonMode=3us LTR1.2_Threshold=61440ns
  00:00.0 L1SubCtl2: T_PwrOn=52us
  01:00.0 L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+
  Link: 5GT/s x1, CommClk+, ClockPM- on both ends

After that, every s2idle entry hangs:

- All devices suspend. With console_suspend=N and pm_debug_messages,
  the last line on the AP UART is "PM: suspend-to-idle".
- The EC sees the AP go S0->S3, and S3->S0 never comes.
- The RTC wake alarm doesn't bring it back. Only a hard reset (EC
  reset through the GSC) recovers the machine.

What works

- L1.1 only, with link/l1_2_aspm and link/l1_2_pcipm cleared: 10/10
  s2idle cycles, RTC wake, Wi-Fi back after each one.
- L1.2 while awake: 200 MB over Wi-Fi with no AER errors and no ping
  loss. At idle it saves another 25-50 mW over L1.1.
- Workaround: clear l1_2_aspm and l1_2_pcipm just before suspend and
  set them again after resume (a systemd sleep hook). 10/10 cycles.
- Adding the L0s and AXI bits above made no difference to the hang.

ChromeOS builds its MediaTek kernels with
CONFIG_PCIEASPM_POWER_SUPERSAVE=y, and the comment in its
mtk_pcie_suspend_noirq() says "It's recommended to enable L1ss
support, so the link can be changed to L1.2 state during suspend."
So L1.2 in SPM sleep seems to be meant to work on this SoC. I haven't
checked the L1SS state under ChromeOS's own kernel on this machine.
Since the AP gets as far as signalling S3, my guess is that something
outside the MAC registers is missing.

Questions

1. Does MT8189 need anything else for L1.2 across SPM sleep? For
   example:
   a) The 26 MHz reference clock and CLKREQ# in L1.2. For MT8196,
      the mainline PCIe sphy keeps pextp_ckm on in L1SS_L1S1
      (RG_XTP_CKM_EN_L1S1). ChromeOS's MT8196 pre_init forces
      pcie_26m_req and bypasses its ack (PEXTPCFG
      PEXTP_REQ_CTRL_0_REG) and switches PEXTP_CLOCK_CON off the
      low-power clock. Is there an MT8189 equivalent? The T-PHY
      driver has no L1SS handling.
   b) A resource request or constraint for the SPM/TF-A, telling it
      that PCIe is in use so that a clock or bus resource stays
      available during sleep.
   c) PCIE_RESOURCE_CTRL_REG SYS_CLK_RDY_TIME. MT8196 sets it to
      10 us; MT8189 leaves it at the reset value.
2. Is anything in the setup above wrong for MT8189? For instance,
   nothing on this DT platform programs the endpoint's LTR Max
   Snoop/No-Snoop Latency (both are 0).

I can test patches, read registers before and after a sleep attempt,
or try other settings. I have the AP and EC consoles and can reset the
machine remotely. The board files and patches are at
https://github.com/zoan37/lenovo-slim3-chromebook-omarchy

The debugging was done with help from an AI assistant (Claude).

Thanks,
zoan37