Re: [PATCH] drm/amd/display: only allow freesync on a VRR_ENABLED crtc

[Leo Li <sunpeng.li@amd.com>]

On 2026-09-21 15:47, Matthew Schwartz wrote:
> Hi George,
> 
> After updating to Linux 7.2.x, I noticed gamescope's frame limiter falling
> below the requested rate. The reproducer was a Navi 33 driving 4K120
> through a DP-HDMI PCON, with VRR disabled. A 40fps limit was producing
> roughly 37fps.
> 
> Gamescope was pacing against the fixed 120Hz refresh interval, but we
> observed frame intervals stretching to around 9.34ms instead of 8.33ms.
> The OTG vtotal also increased from 2249 to 2521. This was enough to
> disrupt the limiter's pacing despite userspace leaving VRR_ENABLED=0.

Hi Matt,

I wonder if this has to do with re-introducing 2-frame vblank off for NV3+
DGPUs, which made it into 7.2:

fba211b078d6 ("Revert "drm/amd/display: Restore 5s vbl offdelay for NV3x+ DGPUs"")

Since gamescope is only updating every 3rd frame, it's possible vblanks were
turned off during those two frames, signaling driver to enable idle optimizations.

To test this idea, does bumping this line to something like 5 frames ((u64)50 *) help?
https://elixir.bootlin.com/linux/v7.3-rc3/source/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L3377

Thanks,
Leo 
> 
> Tracing this led to allow_freesync remaining true for a VRR-capable
> sink even when the FreeSync state was inactive. That allowed FPO to
> stretch vblank around UCLK switches. The PCON whitelist change exposed
> this on our setup by making the sink eligible for that path.
> 
> The intent is to keep the frame period fixed when userspace has
> disabled VRR, while retaining FPO eligibility when variable refresh is
> actually requested. With the patch, the original setup holds the
> requested 40fps again. I also tested VRR toggling on a Legion Go 2's
> internal eDP OLED panel and did not observe a regression.
> 
> Thanks,
> Matt