On Wed, 2026-09-02 at 15:25 -0400, Jake Steinman wrote: > 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.
Best to report this : https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html BR, Jouni Högander
