Follow-up after a day of A/B runs, all negative, each verified in the registers before the run:
- TRANS_VBLANK.VBLANK_START programmed with the real vblank start instead of 0 - guardband forced to the full vblank (127 lines) - PSR2_MAN_TRK_CTL in the pre-ADL-P layout (4-line units) - ALPM_CTL with ALPM enable / keep FEC / AUX wake sleep hold set for PSR2 - IO buffer wake at the 5-line minimum - PSR_DEBUG masking MEMUP only - no PIPE_SRCSZ_ERLY_TPT / DSC SU parameter writes - frames-before-SU 2, idle frames 6 - SW VSC DIP disabled with VSC_SELECT = 3 - sink: CRC verification bit set, MSA timing ignore cleared Individually and all together: two captures after enable, then SU_STANDBY at every frame change, sink 0x200a never reports SU_VALID. Manual TRANS_PUSH SEND, CURSURFLIVE and LNL_SFF_CTL writes with the desktop idle are ignored as well, and PSR2_SU_STATUS stays at the block counts of the two entry captures. I have exhausted what can be derived from the driver source. What would settle this is a register dump from a Panther Lake machine where PSR2 SU or Panel Replay works, taken while it is active: 0x60000-0x610ff, 0x70000-0x707ff, 0x420c0-0x420cf and 0x16fa00-0x16fa7f, plus DPCD 0x2008/0x200a. If anyone at Intel with a PTL eDP system (Windows or Linux) can share such a dump, or point at the Bspec condition the PSR2 engine needs to leave SU_STANDBY on Xe3 LPD with two VDSC streams, I will do the rest. Instrumented kernel, scripts and all run logs are available on request.
