Re: [PATCH 3/3] pmdomain: mediatek: Add power domain driver for MT8189 SoC

[zoan37 <agentzoan@gmail.com>]

Hi Irving,

Some findings from running this driver on an MT8189 Chromebook (Lenovo
IdeaPad Slim 3 Chromebook, board "quigon"), mostly around system
suspend (s2idle through the SPM), on next-20261008.

1. MFG1's EMI GALS sleep-protect step, BUS_PROT_WR_IGN(SMI,
   MT8189_PROT_EN_EMICFG_GALS_SLP_MFG1, ...), targets the EMI config
   block (emicfg_ao_mem at 0x10270000; SET/CLR/RDY at 0x84/0x88/0x8c),
   so on MT8189 the "SMI" regmap has to be that block. Without a
   mediatek,smi phandle in the DT, the step went to the wrong regmap and
   wrote INFRACFG_AO+0x84/0x88 instead, which was one of the causes of
   SErrors after resume here. Giving the MFG1 node
   mediatek,smi = <&emicfg_ao_mem> (a syscon node for 0x10270000) fixed
   it. It may help to document this for MT8189, and possibly to fail
   instead of falling back when a domain uses an SMI step and no SMI
   regmap was found. (access-controllers would be the modern way, but on
   this board fw_devlink then delayed boot by about 10 s waiting for a
   supplier the syscon never gets.)

2. DISP: at runtime it never powers off here (MMSYS, the mutex and the
   DVOs have no runtime PM), but in system suspend genpd tries to, and
   the power-off is rejected part way (genpd debugfs idle_states shows
   "Rejected"). That leaves the display's memory path blocked: after
   resume OVL stalls (no vblanks, larb0 stuck busy) or the display
   faults with an SError shortly after the video unmutes. Marking DISP
   MTK_SCPD_ALWAYS_ON works around it. DISP has a single bus-protect
   step (MMSYS_STA_0) while VDE0 and VEN0 have two (MMSYS_STA_0 and
   STA_1); I don't know whether DISP needs a second one, but something
   in its power-off sequence doesn't complete in this state.

3. PCIe: to keep the Wi-Fi (MT7922) up across s2idle, as ChromeOS does,
   PCIE needs MTK_SCPD_ACTIVE_WAKEUP and both PCIE and PCIE_PHY stay on
   (we use MTK_SCPD_ALWAYS_ON for both).

With these (plus a cpu-s2idle idle state in the DT and a few driver
changes elsewhere), suspend works: repeated suspend/resume cycles pass
(20/20, then 10/10 twice), with RTC, lid and keyboard wake and well
under 0.1 W asleep. The board's patches and notes are at
https://github.com/zoan37/lenovo-slim3-chromebook-omarchy
(port/quigon/patches/mainline-mt8189-suspend.patch).

This was found and tested with help from an AI assistant (Claude).

Thanks,
zoan37