Re: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag behaviour
Hi Ville, > -Original Message- > From: Ville Syrjälä > Sent: 30 August 2023 12:29 > To: Golani, Mitulkumar Ajitkumar > > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag > behaviour > > On Wed, Aug 30, 2023 at 06:51:25AM +, Golani, Mitulkumar Ajitkumar > wrote: > > Hi Ville, > > > > > -Original Message- > > > From: Ville Syrjälä > > > Sent: 30 August 2023 10:47 > > > To: Golani, Mitulkumar Ajitkumar > > > > > > Cc: intel-gfx@lists.freedesktop.org > > > Subject: Re: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n > > > flag behaviour > > > > > > On Tue, Aug 29, 2023 at 01:48:18PM +, Golani, Mitulkumar > > > Ajitkumar > > > wrote: > > > > Hi Ville, > > > > > > > > Thanks for the inputs. > > > > > > > > I encountered an interesting observation while validating the changes. > > > > In scenarios where VRR is by default ON from the panel, I noticed > > > > that > > > during the first-time enabling of VRR, a full modeset is required > > > due to a fastset requirement mismatch, as indicated in the logs. > > > > > > Which logs? > > > > > > > However, I also observed that after this, the function > > > intel_crtc_needs_modeset returns 0, which typically implies a > > > fastset operation. > > > > > > Any fastset always starts out as a full modeset, it will then be > > > promoted (or > > > demoted?) to a fastset by intel_crtc_check_fastset() if possible. > > > > > > > Thank you for your explanation. Considering the underrun issues > > observed during validation, it seems plausible that for the initial > > computation of VRR parameters, a full modeset might be required to > ensure the accurate establishment of the baseline configuration. I > appreciate your insight on this matter. > > Are you saying that these patches alone are causing underruns when > enabling VRR? Currently we are getting underruns with this patch series. However this may be exposing some other underlying problem in the driver. Which requires further investigation. Regards, Mitul > > > > > Regards, > > Mitul > > > > > > > > > > Considering that both conditions can't hold simultaneously, there > > > > seems > > > to be an inconsistency with underrun errors. > > > > Could you kindly shed some light on this situation? I'm trying to > > > > align the > > > log messages with the observed behavior and the function's return > value. > > > > > > > > Your insights would be greatly appreciated. > > > > > > > > Regards, > > > > Mitul > > > > > > > > > -Original Message- > > > > > From: Ville Syrjälä > > > > > Sent: 29 August 2023 13:51 > > > > > To: Golani, Mitulkumar Ajitkumar > > > > > > > > > > Cc: intel-gfx@lists.freedesktop.org > > > > > Subject: Re: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust > > > > > seamless_m_n flag behaviour > > > > > > > > > > On Mon, Aug 28, 2023 at 04:58:49PM +, Golani, Mitulkumar > > > > > Ajitkumar > > > > > wrote: > > > > > > Hi Ville, > > > > > > > > > > > > > -Original Message- > > > > > > > From: Intel-gfx On > > > > > > > Behalf Of Ville Syrjala > > > > > > > Sent: 28 August 2023 11:12 > > > > > > > To: intel-gfx@lists.freedesktop.org > > > > > > > Subject: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust > > > > > > > seamless_m_n flag behaviour > > > > > > > > > > > > > > From: Ville Syrjälä > > > > > > > > > > > > > > Make the seamless_m_n flag more like the update_pipe fastset > > > > > > > flag, ie. the flag will only be set if we need to do the > > > > > > > seamless M/N update, and in all other cases the flag is cleared. > > > > > > > Also rename the flag to update_m_n to make it more clear > > > > > > > it's > > > similar to update_pipe. > > > > > > > > > > > > > > I believe special casing seamless_m_n like this makes sense > > &g
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag behaviour
On Wed, Aug 30, 2023 at 06:51:25AM +, Golani, Mitulkumar Ajitkumar wrote: > Hi Ville, > > > -Original Message- > > From: Ville Syrjälä > > Sent: 30 August 2023 10:47 > > To: Golani, Mitulkumar Ajitkumar > > > > Cc: intel-gfx@lists.freedesktop.org > > Subject: Re: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag > > behaviour > > > > On Tue, Aug 29, 2023 at 01:48:18PM +, Golani, Mitulkumar Ajitkumar > > wrote: > > > Hi Ville, > > > > > > Thanks for the inputs. > > > > > > I encountered an interesting observation while validating the changes. > > > In scenarios where VRR is by default ON from the panel, I noticed that > > during the first-time enabling of VRR, a full modeset is required due to a > > fastset requirement mismatch, as indicated in the logs. > > > > Which logs? > > > > > However, I also observed that after this, the function > > intel_crtc_needs_modeset returns 0, which typically implies a fastset > > operation. > > > > Any fastset always starts out as a full modeset, it will then be promoted > > (or > > demoted?) to a fastset by intel_crtc_check_fastset() if possible. > > > > Thank you for your explanation. Considering the underrun issues observed > during validation, > it seems plausible that for the initial computation of VRR parameters, a full > modeset might be required > to ensure the accurate establishment of the baseline configuration. I > appreciate your insight on this matter. Are you saying that these patches alone are causing underruns when enabling VRR? > > Regards, > Mitul > > > > > > > Considering that both conditions can't hold simultaneously, there seems > > to be an inconsistency with underrun errors. > > > Could you kindly shed some light on this situation? I'm trying to align > > > the > > log messages with the observed behavior and the function's return value. > > > > > > Your insights would be greatly appreciated. > > > > > > Regards, > > > Mitul > > > > > > > -Original Message- > > > > From: Ville Syrjälä > > > > Sent: 29 August 2023 13:51 > > > > To: Golani, Mitulkumar Ajitkumar > > > > > > > > Cc: intel-gfx@lists.freedesktop.org > > > > Subject: Re: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n > > > > flag behaviour > > > > > > > > On Mon, Aug 28, 2023 at 04:58:49PM +, Golani, Mitulkumar > > > > Ajitkumar > > > > wrote: > > > > > Hi Ville, > > > > > > > > > > > -Original Message- > > > > > > From: Intel-gfx On > > > > > > Behalf Of Ville Syrjala > > > > > > Sent: 28 August 2023 11:12 > > > > > > To: intel-gfx@lists.freedesktop.org > > > > > > Subject: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n > > > > > > flag behaviour > > > > > > > > > > > > From: Ville Syrjälä > > > > > > > > > > > > Make the seamless_m_n flag more like the update_pipe fastset > > > > > > flag, ie. the flag will only be set if we need to do the > > > > > > seamless M/N update, and in all other cases the flag is cleared. > > > > > > Also rename the flag to update_m_n to make it more clear it's > > similar to update_pipe. > > > > > > > > > > > > I believe special casing seamless_m_n like this makes sense as > > > > > > it also affects eg. vblank evasion. We can potentially avoid > > > > > > some vblank evasion tricks, simplify some checks, and hopefully > > > > > > will help with > > > > the VRR vs. M/N mess. > > > > > > > > > > > > Signed-off-by: Ville Syrjälä > > > > > > --- > > > > > > drivers/gpu/drm/i915/display/intel_atomic.c | 1 + > > > > > > drivers/gpu/drm/i915/display/intel_crtc.c | 2 +- > > > > > > drivers/gpu/drm/i915/display/intel_display.c | 22 > > > > > > +++-- > > -- > > > > > > .../drm/i915/display/intel_display_types.h| 2 +- > > > > > > drivers/gpu/drm/i915/display/intel_dp.c | 2 +- > > > > > > 5 files changed, 17 insertions(+), 12 deletions(-) > > > > > > > > > > > > diff
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag behaviour
Hi Ville, > -Original Message- > From: Ville Syrjälä > Sent: 30 August 2023 10:47 > To: Golani, Mitulkumar Ajitkumar > > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag > behaviour > > On Tue, Aug 29, 2023 at 01:48:18PM +, Golani, Mitulkumar Ajitkumar > wrote: > > Hi Ville, > > > > Thanks for the inputs. > > > > I encountered an interesting observation while validating the changes. > > In scenarios where VRR is by default ON from the panel, I noticed that > during the first-time enabling of VRR, a full modeset is required due to a > fastset requirement mismatch, as indicated in the logs. > > Which logs? > > > However, I also observed that after this, the function > intel_crtc_needs_modeset returns 0, which typically implies a fastset > operation. > > Any fastset always starts out as a full modeset, it will then be promoted (or > demoted?) to a fastset by intel_crtc_check_fastset() if possible. > Thank you for your explanation. Considering the underrun issues observed during validation, it seems plausible that for the initial computation of VRR parameters, a full modeset might be required to ensure the accurate establishment of the baseline configuration. I appreciate your insight on this matter. Regards, Mitul > > > > Considering that both conditions can't hold simultaneously, there seems > to be an inconsistency with underrun errors. > > Could you kindly shed some light on this situation? I'm trying to align the > log messages with the observed behavior and the function's return value. > > > > Your insights would be greatly appreciated. > > > > Regards, > > Mitul > > > > > -Original Message----- > > > From: Ville Syrjälä > > > Sent: 29 August 2023 13:51 > > > To: Golani, Mitulkumar Ajitkumar > > > > > > Cc: intel-gfx@lists.freedesktop.org > > > Subject: Re: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n > > > flag behaviour > > > > > > On Mon, Aug 28, 2023 at 04:58:49PM +, Golani, Mitulkumar > > > Ajitkumar > > > wrote: > > > > Hi Ville, > > > > > > > > > -Original Message- > > > > > From: Intel-gfx On > > > > > Behalf Of Ville Syrjala > > > > > Sent: 28 August 2023 11:12 > > > > > To: intel-gfx@lists.freedesktop.org > > > > > Subject: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n > > > > > flag behaviour > > > > > > > > > > From: Ville Syrjälä > > > > > > > > > > Make the seamless_m_n flag more like the update_pipe fastset > > > > > flag, ie. the flag will only be set if we need to do the > > > > > seamless M/N update, and in all other cases the flag is cleared. > > > > > Also rename the flag to update_m_n to make it more clear it's > similar to update_pipe. > > > > > > > > > > I believe special casing seamless_m_n like this makes sense as > > > > > it also affects eg. vblank evasion. We can potentially avoid > > > > > some vblank evasion tricks, simplify some checks, and hopefully > > > > > will help with > > > the VRR vs. M/N mess. > > > > > > > > > > Signed-off-by: Ville Syrjälä > > > > > --- > > > > > drivers/gpu/drm/i915/display/intel_atomic.c | 1 + > > > > > drivers/gpu/drm/i915/display/intel_crtc.c | 2 +- > > > > > drivers/gpu/drm/i915/display/intel_display.c | 22 +++-- > -- > > > > > .../drm/i915/display/intel_display_types.h| 2 +- > > > > > drivers/gpu/drm/i915/display/intel_dp.c | 2 +- > > > > > 5 files changed, 17 insertions(+), 12 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c > > > > > b/drivers/gpu/drm/i915/display/intel_atomic.c > > > > > index 7cf51dd8c056..aaddd8c0cfa0 100644 > > > > > --- a/drivers/gpu/drm/i915/display/intel_atomic.c > > > > > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c > > > > > @@ -259,6 +259,7 @@ intel_crtc_duplicate_state(struct drm_crtc > *crtc) > > > > > drm_property_blob_get(crtc_state->post_csc_lut); > > > > > > > > > > crtc_state->update_pipe = false; > > > > > + crtc_state->update_m_n = false; > > > > &g
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag behaviour
On Tue, Aug 29, 2023 at 01:48:18PM +, Golani, Mitulkumar Ajitkumar wrote: > Hi Ville, > > Thanks for the inputs. > > I encountered an interesting observation while validating the changes. > In scenarios where VRR is by default ON from the panel, I noticed that during > the first-time enabling of VRR, a full modeset is required due to a fastset > requirement mismatch, as indicated in the logs. Which logs? > However, I also observed that after this, the function > intel_crtc_needs_modeset returns 0, which typically implies a fastset > operation. Any fastset always starts out as a full modeset, it will then be promoted (or demoted?) to a fastset by intel_crtc_check_fastset() if possible. > > Considering that both conditions can't hold simultaneously, there seems to be > an inconsistency with underrun errors. > Could you kindly shed some light on this situation? I'm trying to align the > log messages with the observed behavior and the function's return value. > > Your insights would be greatly appreciated. > > Regards, > Mitul > > > -Original Message- > > From: Ville Syrjälä > > Sent: 29 August 2023 13:51 > > To: Golani, Mitulkumar Ajitkumar > > > > Cc: intel-gfx@lists.freedesktop.org > > Subject: Re: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag > > behaviour > > > > On Mon, Aug 28, 2023 at 04:58:49PM +, Golani, Mitulkumar Ajitkumar > > wrote: > > > Hi Ville, > > > > > > > -Original Message- > > > > From: Intel-gfx On Behalf > > > > Of Ville Syrjala > > > > Sent: 28 August 2023 11:12 > > > > To: intel-gfx@lists.freedesktop.org > > > > Subject: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag > > > > behaviour > > > > > > > > From: Ville Syrjälä > > > > > > > > Make the seamless_m_n flag more like the update_pipe fastset flag, > > > > ie. the flag will only be set if we need to do the seamless M/N > > > > update, and in all other cases the flag is cleared. Also rename the > > > > flag to update_m_n to make it more clear it's similar to update_pipe. > > > > > > > > I believe special casing seamless_m_n like this makes sense as it > > > > also affects eg. vblank evasion. We can potentially avoid some > > > > vblank evasion tricks, simplify some checks, and hopefully will help > > > > with > > the VRR vs. M/N mess. > > > > > > > > Signed-off-by: Ville Syrjälä > > > > --- > > > > drivers/gpu/drm/i915/display/intel_atomic.c | 1 + > > > > drivers/gpu/drm/i915/display/intel_crtc.c | 2 +- > > > > drivers/gpu/drm/i915/display/intel_display.c | 22 +++ > > > > .../drm/i915/display/intel_display_types.h| 2 +- > > > > drivers/gpu/drm/i915/display/intel_dp.c | 2 +- > > > > 5 files changed, 17 insertions(+), 12 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c > > > > b/drivers/gpu/drm/i915/display/intel_atomic.c > > > > index 7cf51dd8c056..aaddd8c0cfa0 100644 > > > > --- a/drivers/gpu/drm/i915/display/intel_atomic.c > > > > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c > > > > @@ -259,6 +259,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc) > > > > drm_property_blob_get(crtc_state->post_csc_lut); > > > > > > > > crtc_state->update_pipe = false; > > > > + crtc_state->update_m_n = false; > > > > crtc_state->disable_lp_wm = false; > > > > crtc_state->disable_cxsr = false; > > > > crtc_state->update_wm_pre = false; diff --git > > > > a/drivers/gpu/drm/i915/display/intel_crtc.c > > > > b/drivers/gpu/drm/i915/display/intel_crtc.c > > > > index 1992e7060263..a04076064f02 100644 > > > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c > > > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c > > > > @@ -510,7 +510,7 @@ static void > > > > intel_crtc_vblank_evade_scanlines(struct > > > > intel_atomic_state *state, > > > > * M/N is double buffered on the transcoder's undelayed vblank, > > > > * so with seamless M/N we must evade both vblanks. > > > > */ > > > > - if (new_crtc_state->seamless_m_n && > > > > intel_crtc_n
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag behaviour
Hi Ville,
Thanks for the inputs.
I encountered an interesting observation while validating the changes.
In scenarios where VRR is by default ON from the panel, I noticed that during
the first-time enabling of VRR, a full modeset is required due to a fastset
requirement mismatch, as indicated in the logs.
However, I also observed that after this, the function intel_crtc_needs_modeset
returns 0, which typically implies a fastset operation.
Considering that both conditions can't hold simultaneously, there seems to be
an inconsistency with underrun errors.
Could you kindly shed some light on this situation? I'm trying to align the log
messages with the observed behavior and the function's return value.
Your insights would be greatly appreciated.
Regards,
Mitul
> -Original Message-
> From: Ville Syrjälä
> Sent: 29 August 2023 13:51
> To: Golani, Mitulkumar Ajitkumar
>
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag
> behaviour
>
> On Mon, Aug 28, 2023 at 04:58:49PM +, Golani, Mitulkumar Ajitkumar
> wrote:
> > Hi Ville,
> >
> > > -Original Message-
> > > From: Intel-gfx On Behalf
> > > Of Ville Syrjala
> > > Sent: 28 August 2023 11:12
> > > To: intel-gfx@lists.freedesktop.org
> > > Subject: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag
> > > behaviour
> > >
> > > From: Ville Syrjälä
> > >
> > > Make the seamless_m_n flag more like the update_pipe fastset flag,
> > > ie. the flag will only be set if we need to do the seamless M/N
> > > update, and in all other cases the flag is cleared. Also rename the
> > > flag to update_m_n to make it more clear it's similar to update_pipe.
> > >
> > > I believe special casing seamless_m_n like this makes sense as it
> > > also affects eg. vblank evasion. We can potentially avoid some
> > > vblank evasion tricks, simplify some checks, and hopefully will help with
> the VRR vs. M/N mess.
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/display/intel_atomic.c | 1 +
> > > drivers/gpu/drm/i915/display/intel_crtc.c | 2 +-
> > > drivers/gpu/drm/i915/display/intel_display.c | 22 +++
> > > .../drm/i915/display/intel_display_types.h| 2 +-
> > > drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> > > 5 files changed, 17 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> > > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > index 7cf51dd8c056..aaddd8c0cfa0 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > @@ -259,6 +259,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> > > drm_property_blob_get(crtc_state->post_csc_lut);
> > >
> > > crtc_state->update_pipe = false;
> > > + crtc_state->update_m_n = false;
> > > crtc_state->disable_lp_wm = false;
> > > crtc_state->disable_cxsr = false;
> > > crtc_state->update_wm_pre = false; diff --git
> > > a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > index 1992e7060263..a04076064f02 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > @@ -510,7 +510,7 @@ static void
> > > intel_crtc_vblank_evade_scanlines(struct
> > > intel_atomic_state *state,
> > >* M/N is double buffered on the transcoder's undelayed vblank,
> > >* so with seamless M/N we must evade both vblanks.
> > >*/
> > > - if (new_crtc_state->seamless_m_n &&
> > > intel_crtc_needs_fastset(new_crtc_state))
> > > + if (new_crtc_state->update_m_n)
> > > *min -= adjusted_mode->crtc_vblank_start -
> > > adjusted_mode->crtc_vdisplay; }
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 632f1f58df9e..6196ef76390b 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -5170,7 +5170,7 @@ intel_pipe_config_compare(const struct
> > > intel_crtc_state *current_config,
> > > PIPE_CONF_CHECK_X(lane_lat_optim_mask);
> > >
> > > if (HAS_DOUBLE_BUFFERED_M_N(dev_priv)) {
> > > -
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag behaviour
On Mon, Aug 28, 2023 at 04:58:49PM +, Golani, Mitulkumar Ajitkumar wrote:
> Hi Ville,
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of Ville
> > Syrjala
> > Sent: 28 August 2023 11:12
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag
> > behaviour
> >
> > From: Ville Syrjälä
> >
> > Make the seamless_m_n flag more like the update_pipe fastset flag, ie. the
> > flag will only be set if we need to do the seamless M/N update, and in all
> > other cases the flag is cleared. Also rename the flag to update_m_n to
> > make it more clear it's similar to update_pipe.
> >
> > I believe special casing seamless_m_n like this makes sense as it also
> > affects
> > eg. vblank evasion. We can potentially avoid some vblank evasion tricks,
> > simplify some checks, and hopefully will help with the VRR vs. M/N mess.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_atomic.c | 1 +
> > drivers/gpu/drm/i915/display/intel_crtc.c | 2 +-
> > drivers/gpu/drm/i915/display/intel_display.c | 22 +++
> > .../drm/i915/display/intel_display_types.h| 2 +-
> > drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> > 5 files changed, 17 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > index 7cf51dd8c056..aaddd8c0cfa0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > @@ -259,6 +259,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> > drm_property_blob_get(crtc_state->post_csc_lut);
> >
> > crtc_state->update_pipe = false;
> > + crtc_state->update_m_n = false;
> > crtc_state->disable_lp_wm = false;
> > crtc_state->disable_cxsr = false;
> > crtc_state->update_wm_pre = false;
> > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > index 1992e7060263..a04076064f02 100644
> > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > @@ -510,7 +510,7 @@ static void intel_crtc_vblank_evade_scanlines(struct
> > intel_atomic_state *state,
> > * M/N is double buffered on the transcoder's undelayed vblank,
> > * so with seamless M/N we must evade both vblanks.
> > */
> > - if (new_crtc_state->seamless_m_n &&
> > intel_crtc_needs_fastset(new_crtc_state))
> > + if (new_crtc_state->update_m_n)
> > *min -= adjusted_mode->crtc_vblank_start -
> > adjusted_mode->crtc_vdisplay; }
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 632f1f58df9e..6196ef76390b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -5170,7 +5170,7 @@ intel_pipe_config_compare(const struct
> > intel_crtc_state *current_config,
> > PIPE_CONF_CHECK_X(lane_lat_optim_mask);
> >
> > if (HAS_DOUBLE_BUFFERED_M_N(dev_priv)) {
> > - if (!fastset || !pipe_config->seamless_m_n)
> > + if (!fastset || !pipe_config->update_m_n)
> > PIPE_CONF_CHECK_M_N(dp_m_n);
> > } else {
> > PIPE_CONF_CHECK_M_N(dp_m_n);
> > @@ -5307,7 +5307,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->update_m_n) {
> > PIPE_CONF_CHECK_I(hw.pipe_mode.crtc_clock);
> > PIPE_CONF_CHECK_I(hw.adjusted_mode.crtc_clock);
> > }
> > @@ -5402,6 +5402,7 @@ int intel_modeset_all_pipes(struct
> > intel_atomic_state *state,
> >
> > crtc_state->uapi.mode_changed = true;
> > crtc_state->update_pipe = false;
> > + crtc_state->update_m_n = false;
> >
> > ret = drm_atomic_add_affected_connectors(>base,
> > >base);
> > @@ -5519,13 +5520,14 @@ static void intel_crtc_check_fastset(const struct
> > intel_crtc_state *old_crtc_sta {
> > struct dr
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag behaviour
Hi Ville,
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: 28 August 2023 11:12
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag
> behaviour
>
> From: Ville Syrjälä
>
> Make the seamless_m_n flag more like the update_pipe fastset flag, ie. the
> flag will only be set if we need to do the seamless M/N update, and in all
> other cases the flag is cleared. Also rename the flag to update_m_n to
> make it more clear it's similar to update_pipe.
>
> I believe special casing seamless_m_n like this makes sense as it also affects
> eg. vblank evasion. We can potentially avoid some vblank evasion tricks,
> simplify some checks, and hopefully will help with the VRR vs. M/N mess.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_atomic.c | 1 +
> drivers/gpu/drm/i915/display/intel_crtc.c | 2 +-
> drivers/gpu/drm/i915/display/intel_display.c | 22 +++
> .../drm/i915/display/intel_display_types.h| 2 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> 5 files changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index 7cf51dd8c056..aaddd8c0cfa0 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -259,6 +259,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> drm_property_blob_get(crtc_state->post_csc_lut);
>
> crtc_state->update_pipe = false;
> + crtc_state->update_m_n = false;
> crtc_state->disable_lp_wm = false;
> crtc_state->disable_cxsr = false;
> crtc_state->update_wm_pre = false;
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 1992e7060263..a04076064f02 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -510,7 +510,7 @@ static void intel_crtc_vblank_evade_scanlines(struct
> intel_atomic_state *state,
>* M/N is double buffered on the transcoder's undelayed vblank,
>* so with seamless M/N we must evade both vblanks.
>*/
> - if (new_crtc_state->seamless_m_n &&
> intel_crtc_needs_fastset(new_crtc_state))
> + if (new_crtc_state->update_m_n)
> *min -= adjusted_mode->crtc_vblank_start -
> adjusted_mode->crtc_vdisplay; }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 632f1f58df9e..6196ef76390b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5170,7 +5170,7 @@ intel_pipe_config_compare(const struct
> intel_crtc_state *current_config,
> PIPE_CONF_CHECK_X(lane_lat_optim_mask);
>
> if (HAS_DOUBLE_BUFFERED_M_N(dev_priv)) {
> - if (!fastset || !pipe_config->seamless_m_n)
> + if (!fastset || !pipe_config->update_m_n)
> PIPE_CONF_CHECK_M_N(dp_m_n);
> } else {
> PIPE_CONF_CHECK_M_N(dp_m_n);
> @@ -5307,7 +5307,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->update_m_n) {
> PIPE_CONF_CHECK_I(hw.pipe_mode.crtc_clock);
> PIPE_CONF_CHECK_I(hw.adjusted_mode.crtc_clock);
> }
> @@ -5402,6 +5402,7 @@ int intel_modeset_all_pipes(struct
> intel_atomic_state *state,
>
> crtc_state->uapi.mode_changed = true;
> crtc_state->update_pipe = false;
> + crtc_state->update_m_n = false;
>
> ret = drm_atomic_add_affected_connectors(>base,
>>base);
> @@ -5519,13 +5520,14 @@ static void intel_crtc_check_fastset(const struct
> intel_crtc_state *old_crtc_sta {
> struct drm_i915_private *i915 = to_i915(old_crtc_state->uapi.crtc-
> >dev);
>
> - if (!intel_pipe_config_compare(old_crtc_state, new_crtc_state,
> true)) {
> + if (!intel_pipe_config_compare(old_crtc_state, new_crtc_state,
> true))
> drm_dbg_kms(>drm, "fastset requirement not met,
> forcing full modeset\n");
> + else
> + new_crtc_state->uapi.mode_changed = false;
>
> - return;
> - }
> + if
[Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag behaviour
From: Ville Syrjälä
Make the seamless_m_n flag more like the update_pipe fastset
flag, ie. the flag will only be set if we need to do the seamless
M/N update, and in all other cases the flag is cleared. Also
rename the flag to update_m_n to make it more clear it's similar
to update_pipe.
I believe special casing seamless_m_n like this makes sense
as it also affects eg. vblank evasion. We can potentially avoid
some vblank evasion tricks, simplify some checks, and hopefully
will help with the VRR vs. M/N mess.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic.c | 1 +
drivers/gpu/drm/i915/display/intel_crtc.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 22 +++
.../drm/i915/display/intel_display_types.h| 2 +-
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
5 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 7cf51dd8c056..aaddd8c0cfa0 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -259,6 +259,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
drm_property_blob_get(crtc_state->post_csc_lut);
crtc_state->update_pipe = false;
+ crtc_state->update_m_n = false;
crtc_state->disable_lp_wm = false;
crtc_state->disable_cxsr = false;
crtc_state->update_wm_pre = false;
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
b/drivers/gpu/drm/i915/display/intel_crtc.c
index 1992e7060263..a04076064f02 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -510,7 +510,7 @@ static void intel_crtc_vblank_evade_scanlines(struct
intel_atomic_state *state,
* M/N is double buffered on the transcoder's undelayed vblank,
* so with seamless M/N we must evade both vblanks.
*/
- if (new_crtc_state->seamless_m_n &&
intel_crtc_needs_fastset(new_crtc_state))
+ if (new_crtc_state->update_m_n)
*min -= adjusted_mode->crtc_vblank_start -
adjusted_mode->crtc_vdisplay;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 632f1f58df9e..6196ef76390b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5170,7 +5170,7 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
PIPE_CONF_CHECK_X(lane_lat_optim_mask);
if (HAS_DOUBLE_BUFFERED_M_N(dev_priv)) {
- if (!fastset || !pipe_config->seamless_m_n)
+ if (!fastset || !pipe_config->update_m_n)
PIPE_CONF_CHECK_M_N(dp_m_n);
} else {
PIPE_CONF_CHECK_M_N(dp_m_n);
@@ -5307,7 +5307,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->update_m_n) {
PIPE_CONF_CHECK_I(hw.pipe_mode.crtc_clock);
PIPE_CONF_CHECK_I(hw.adjusted_mode.crtc_clock);
}
@@ -5402,6 +5402,7 @@ int intel_modeset_all_pipes(struct intel_atomic_state
*state,
crtc_state->uapi.mode_changed = true;
crtc_state->update_pipe = false;
+ crtc_state->update_m_n = false;
ret = drm_atomic_add_affected_connectors(>base,
>base);
@@ -5519,13 +5520,14 @@ static void intel_crtc_check_fastset(const struct
intel_crtc_state *old_crtc_sta
{
struct drm_i915_private *i915 = to_i915(old_crtc_state->uapi.crtc->dev);
- if (!intel_pipe_config_compare(old_crtc_state, new_crtc_state, true)) {
+ if (!intel_pipe_config_compare(old_crtc_state, new_crtc_state, true))
drm_dbg_kms(>drm, "fastset requirement not met, forcing
full modeset\n");
+ else
+ new_crtc_state->uapi.mode_changed = false;
- return;
- }
+ if (intel_crtc_needs_modeset(new_crtc_state))
+ new_crtc_state->update_m_n = false;
- new_crtc_state->uapi.mode_changed = false;
if (!intel_crtc_needs_modeset(new_crtc_state))
new_crtc_state->update_pipe = true;
}
@@ -6240,6 +6242,7 @@ int intel_atomic_check(struct drm_device *dev,
if (intel_cpu_transcoders_need_modeset(state,
BIT(master))) {
new_crtc_state->uapi.mode_changed = true;
new_crtc_state->update_pipe = false;
+ new_crtc_state->update_m_n = false;
}
}
@@ -6252,6 +6255,7 @@ int intel_atomic_check(struct drm_device *dev,
