[Intel-gfx] [PATCH v4] drm/i915/display: Dual refresh rate fastset fixes with VRR fastset
Manasi Navare
navaremanasi at chromium.org
Thu Aug 24 16:03:27 UTC 2023
Hi @Jani Nikula ,
Thanks for your feedback. Please find my comments below:
On Thu, Aug 24, 2023 at 4:27 AM Jani Nikula <jani.nikula at linux.intel.com> wrote:
>
> On Fri, 18 Aug 2023, Manasi Navare <navaremanasi at chromium.org> wrote:
> > Dual refresh rate (DRR) fastset seamlessly lets refresh rate
> > throttle without needing a full modeset.
> > However with the recent VRR fastset patches that got merged this
> > logic was broken. This is broken because now with VRR fastset
> > VRR parameters are calculated by default at the nominal refresh rate say 120Hz.
> > Now when DRR throttle happens to switch refresh rate to 60Hz, crtc clock
> > changes and this throws a mismatch in VRR parameters and fastset logic
> > for DRR gets thrown off and full modeset is indicated.
> >
> > This patch fixes this by ignoring the pipe mismatch for VRR parameters
> > in the case of DRR and when VRR is not enabled. With this fix, DRR
> > will still throttle seamlessly as long as VRR is not enabled.
> >
> > This will still need a full modeset for both DRR and VRR operating together
> > during the refresh rate throttle and then enabling VRR since now VRR
> > parameters need to be recomputed with new crtc clock and written to HW.
> >
> > This DRR + VRR fastset in conjunction needs more work in the driver and
> > will be fixed in later patches.
> >
> > v3:
> > Compute new VRR params whenever there is fastset and its non DRRS.
> > This will ensure it computes while switching to a fixed RR (Mitul)
> >
> > v2:
> > Check for pipe config mismatch in crtc clock whenever VRR is enabled
> >
> > Fixes: 1af1d18825d3 ("drm/i915/vrr: Allow VRR to be toggled during fastsets")
>
> How could this have broken fastsets, when this made it possible to do
> vrr enable/disable fastsets to begin with? I was hoping to get a
> regressing commit to make this easier to reason.
Actually this patch enabled VRR fastsets and because of that it actually broke
the logic of DRR/DRRS fastsets. To pinpoint the exact regression patch
is the one that started computing VRR parameters always irrespective
of VRR enable because that started causing pipe mismatches in the
working DRR fastset case.
That patch would be : "drm/i915/vrr: Relocate VRR enable/disable". I
will add this exact regression patch there as per your feedback.
Regards
Manasi
>
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9154
> > Cc: Drew Davenport <ddavenport at chromium.org>
> > Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > Cc: Sean Paul <seanpaul at chromium.org>
> > Cc: Mitul Golani <mitulkumar.ajitkumar.golani at intel.com>
> > Signed-off-by: Manasi Navare <navaremanasi at chromium.org>
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++------
> > 1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> > index 763ab569d8f3..2cf3b22adaf7 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -5352,7 +5352,7 @@ intel_pipe_config_compare(const struct intel_crtc_state *current_config,
> > if (IS_G4X(dev_priv) || DISPLAY_VER(dev_priv) >= 5)
> > PIPE_CONF_CHECK_I(pipe_bpp);
> >
> > - if (!fastset || !pipe_config->seamless_m_n) {
> > + if (!fastset || !pipe_config->seamless_m_n || pipe_config->vrr.enable) {
> > PIPE_CONF_CHECK_I(hw.pipe_mode.crtc_clock);
> > PIPE_CONF_CHECK_I(hw.adjusted_mode.crtc_clock);
> > }
> > @@ -5387,11 +5387,13 @@ intel_pipe_config_compare(const struct intel_crtc_state *current_config,
> >
> > if (!fastset)
> > PIPE_CONF_CHECK_BOOL(vrr.enable);
> > - 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);
> > + if ((fastset && !pipe_config->seamless_m_n) || pipe_config->vrr.enable) {
>
> I just don't get the conditions here and above. For example, why
> wouldn't we check the parameters e.g. on full modeset that disables vrr?
>
> I think we'll need a matrix of the features, which of them can be
> combined together, which are mutually exclusive, and which are expected
> to be fastsets.
>
> BR,
> Jani.
>
>
> > + 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);
> > + }
> >
> > #undef PIPE_CONF_CHECK_X
> > #undef PIPE_CONF_CHECK_I
>
> --
> Jani Nikula, Intel Open Source Graphics Center
More information about the Intel-gfx
mailing list