Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
Equinix is shutting down its operations with us on April 30, 2025. They have graciously supported us for almost 5 years, but all good things come to an end. We are expecting to transition to new infrastructure between late March and mid-April. We do not yet have a firm timeline for this, but it will involve (probably multiple) periods of downtime as we move our services whilst also changing them to be faster and more responsive. Any updates will be posted in freedesktop/freedesktop#2011 as it becomes clear, and any downtime will be announced with further broadcast messages.
Project 'drm/intel' was moved to 'drm/i915/kernel'. Please update any links and bookmarks that may still have the old path.
VRR eDP panel also with sync polarity difference 165/60 does full modeset (not fastset) between refresh rate change
[ 38.904847] i915 0000:00:02.0: [drm:pipe_config_mismatch] [CRTC:80:pipe A] fastset mismatch in vrr.vmin (expected 1732, found 0)
[ 38.904857] i915 0000:00:02.0: [drm:pipe_config_mismatch] [CRTC:80:pipe A] fastset mismatch in vrr.vmax (expected 4763, found 0)
[ 38.904864] i915 0000:00:02.0: [drm:pipe_config_mismatch] [CRTC:80:pipe A] fastset mismatch in vrr.flipline (expected 1733, found 0)
[ 38.904871] i915 0000:00:02.0: [drm:pipe_config_mismatch] [CRTC:80:pipe A] fastset mismatch in vrr.guardband (expected 133, found 0)
Can VRR panel also accommodate seamless refresh rate change? We need fastset beween 165 and 60Hz on this panel. Kindly help with the same. Thank you very much.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Thanks @vsrini4 for testing the patch, I tested this with Brya (ADL-P) based Chromebook and the throttle between 120 - 60Hz works without a full modeset with this patch. I will take a look at the logs and if needed send a v2.
Are the logs attached by you the boot logs? Is it possible for you to try throttling to 60Hz and see if that happens seamlessly?
Hi @vsrini4 , I have uploaded the rev2 : https://patchwork.freedesktop.org/patch/552524/?series=122252&rev=2 . I have tested this with the ADL-P based chromebook and it seems to do DRR throttle from high refresh to lower refresh rate now seamlessly without a full modeset and I am not seeing any underruns.
Let me know how this goes on the edp panel that you have.
Still this mismatch logs seen, when we switch mode to any of fixed refresh rate mode.
[ 102.316102] i915 0000:00:02.0: [drm] ERROR [CRTC:80:pipe A] mismatch in vrr.vmin (expected 0, found 1120)
[ 102.316107] i915 0000:00:02.0: [drm] ERROR [CRTC:80:pipe A] mismatch in vrr.vmax (expected 0, found 6720)
[ 102.316112] i915 0000:00:02.0: [drm] ERROR [CRTC:80:pipe A] mismatch in vrr.flipline (expected 0, found 1121)
[ 102.316116] i915 0000:00:02.0: [drm] ERROR [CRTC:80:pipe A] mismatch in vrr.guardband (expected 0, found 41)
[ 102.316120] ------------[ cut here ]------------
[ 102.316123] i915 0000:00:02.0: pipe state doesn't match!
To avoid this scenario in case of switching to fixed refresh rate mode,
I tried with quick check with following patch modification, which avoids this call trace. and attached validation logs for switching between available refresh rates and vrr enabling scenario.
Thanks for the patch, so basically here this will take care of the scenario where we are disabling VRR and switching back to fixed RR and at that point, it will still recompute the VRR parameters and do a full modeset to write those to the HW regs and then switch to the fixed RR 60Hz.
@vsrini4 could you test this patch if it works on your Hades project?
And with my patch: https://patchwork.freedesktop.org/patch/552660/?series=122252&rev=3 these errors go away and exactly my explanation about VRR parameters mismatch in the patch commit message. Thats why its really important for us to land this patch so the switching between high refresh to low refresh rate works for us in the fastset fashion.
Mitul suggested one more change -> vrr.flipline check instead of vrr.enable
if ((fastset && !pipe_config->seamless_m_n) || pipe_config->vrr.flipline) {
PIPE_CONF_CHECK_I(vrr.vmin);
PIPE_CONF_CHECK_I(vrr.vmax);
PIPE_CONF_CHECK_I(vrr.flipline);
PIPE_CONF_CHECK_I(vrr.pipeline_full);
PIPE_CONF_CHECK_I(vrr.guardband);
}
So, instead of vrr.enable of your patch, he used vrr.flipline and with that during boot no underrun is seen. 165Hz to 60 Hz seamless DRRS is also able to work. But again 60 to 165 VRR mismatch is seen. Attaching logs from Mitul's changes mitul_flipline_drrs.txt.
He mentioned, when RR is changing between 165 to 60 the VRR parameters (vrr.min, vrr.max etc) are all resetting. He will check if only vrr disable/enable can be done without these parameters getting reset/modified between RR change. Mitul, kindly correct me if I am wrong.
I am attaching default logs once again here for reference.
I think on Mitul's feedback on VRR parameters changing when RR changes from 60 to 165 Hz, that is expected. When the RR changes, it is expected that VRR parameters will be different and in that case now if VRR is enabled then that will need a full modeset. This behviour is expected based on the current driver implementation and that should be okay for now.
Meanwhile I am also working on a further change in the driver behaviour where I am trying to reprogram the VRR min/max and flipline regs also at the time VRR en is programmed in the fastset way without needing a full modeset.
I think we cannot use vrr.flipline check there because that will change everytime the throttle in DRR happens between RR and will trigger a full modeset even when vrr is not enabled. We only want a full modeset when the RR changes and if VRR is enabled. So keeping that condition with VRR enable is important.
Thank you for sharing the test results.
As far as the VRR mismatches in case of Ville's series, that is expected since his series doesnt change the behavior around computing VRR parameters in fastset fashion yet. This is just a prep series and the next set of patches that Ville sends should address this.