[Intel-gfx] [PATCH 1/3] drm/i915: Move vrr push after the frame counter sampling again

[Intel-gfx] [PATCH 1/3] drm/i915: Move vrr push after the frame counter sampling again

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

Moving the vrr push to happen before sampling the frame counter
was wrong. If we are already in vblank when the push is sent
the vblank exit will start immediately which causes the sampled
frame counter to correspond to the next frame instead of the current
frame.

So put things back into the original order (except we should
keep the vrr push within the irq disable section to avoid
pointless irq related delays here).

We'll just have to accept the tiny race that exists between
sampling the frame counter vs. vrr push. And let's at least
document said race properly in a comment.

I suppose we could try to minimize the race by sampling the frame
counter just before sending the push, but that would require
changing drm_crtc_arm_vblank_event() to accept a caller provided
vblank counter value, so leave it be for now. Another thing we
could do is change the vblank evasion to account for the case
where a push was already sent. That would anyway be required
for mailbox style updates. Currently mailbox updates are only
used by the legacy cursor, but we don't do a vrr push for those.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Fixes: 6f9976bd1310 ("drm/i915: Do vrr push before sampling the frame counter")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/display/intel_crtc.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
index f09df2cf052b..cf403be7736c 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -610,9 +610,6 @@ void intel_pipe_update_end(struct intel_crtc_state *new_crtc_state)
 
 	trace_intel_pipe_update_end(crtc, end_vbl_count, scanline_end);
 
-	/* Send VRR Push to terminate Vblank */
-	intel_vrr_send_push(new_crtc_state);
-
 	/*
 	 * Incase of mipi dsi command mode, we need to set frame update
 	 * request for every commit.
@@ -641,6 +638,22 @@ void intel_pipe_update_end(struct intel_crtc_state *new_crtc_state)
 		new_crtc_state->uapi.event = NULL;
 	}
 
+	/*
+	 * Send VRR Push to terminate Vblank. If we are already in vblank
+	 * this has to be done _after_ sampling the frame counter, as
+	 * otherwise the push would immediately terminate the vblank and
+	 * the sampled frame counter would correspond to the next frame
+	 * instead of the current frame.
+	 *
+	 * There is a tiny race here (iff vblank evasion failed us) where
+	 * we might sample the frame counter just before vmax vblank start
+	 * but the push would be sent just after it. That would cause the
+	 * push to affect the next frame instead of the current frame,
+	 * which would cause the next frame to terminate already at vmin
+	 * vblank start instead of vmax vblank start.
+	 */
+	intel_vrr_send_push(new_crtc_state);
+
 	local_irq_enable();
 
 	if (intel_vgpu_active(dev_priv))
-- 
2.32.0

[Intel-gfx] [PATCH 2/3] drm/i915: Do vblank evasion correctly if vrr push has already been sent

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

Let's adjust the vblank evasion to account for the case where
a push has already been sent. In that case the vblank exit will start
at vmin vblank start (as opposed to vmax vblank start when no push
has been sent).

This should minimize the effects of the tiny race between sampling
the frame counter vs. intel_vrr_send_push() during the previous frame.
This will also be required if we want to do mailbox style updates with
vrr since then we'd definitely do multiple commits per frame. Currently
mailbox updates are only used by the legacy cursor, but we don't do
vrr push for those.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/display/intel_crtc.c | 10 +++++++---
 drivers/gpu/drm/i915/display/intel_vrr.c  | 12 ++++++++++++
 drivers/gpu/drm/i915/display/intel_vrr.h  |  1 +
 3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
index cf403be7736c..eb5444f90e77 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -470,10 +470,14 @@ void intel_pipe_update_start(struct intel_crtc_state *new_crtc_state)
 	if (intel_crtc_needs_vblank_work(new_crtc_state))
 		intel_crtc_vblank_work_init(new_crtc_state);
 
-	if (new_crtc_state->vrr.enable)
-		vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
-	else
+	if (new_crtc_state->vrr.enable) {
+		if (intel_vrr_is_push_sent(new_crtc_state))
+			vblank_start = intel_vrr_vmin_vblank_start(new_crtc_state);
+		else
+			vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
+	} else {
 		vblank_start = intel_mode_vblank_start(adjusted_mode);
+	}
 
 	/* FIXME needs to be calibrated sensibly */
 	min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
index c335b1dbafcf..db1c3902fc2d 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.c
+++ b/drivers/gpu/drm/i915/display/intel_vrr.c
@@ -193,6 +193,18 @@ void intel_vrr_send_push(const struct intel_crtc_state *crtc_state)
 		       TRANS_PUSH_EN | TRANS_PUSH_SEND);
 }
 
+bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state)
+{
+	struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+	struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+
+	if (!crtc_state->vrr.enable)
+		return false;
+
+	return intel_de_read(dev_priv, TRANS_PUSH(cpu_transcoder)) & TRANS_PUSH_SEND;
+}
+
 void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state)
 {
 	struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.h b/drivers/gpu/drm/i915/display/intel_vrr.h
index 96f9c9c27ab9..1c2da572693d 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.h
+++ b/drivers/gpu/drm/i915/display/intel_vrr.h
@@ -23,6 +23,7 @@ void intel_vrr_compute_config(struct intel_crtc_state *crtc_state,
 void intel_vrr_enable(struct intel_encoder *encoder,
 		      const struct intel_crtc_state *crtc_state);
 void intel_vrr_send_push(const struct intel_crtc_state *crtc_state);
+bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state);
 void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state);
 void intel_vrr_get_config(struct intel_crtc *crtc,
 			  struct intel_crtc_state *crtc_state);
-- 
2.32.0

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Do vblank evasion correctly if vrr push has already been sent

[Navare, Manasi]

On Wed, Nov 17, 2021 at 08:31:02PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Let's adjust the vblank evasion to account for the case where
> a push has already been sent. In that case the vblank exit will start
> at vmin vblank start (as opposed to vmax vblank start when no push
> has been sent).
> 
> This should minimize the effects of the tiny race between sampling
> the frame counter vs. intel_vrr_send_push() during the previous frame.
> This will also be required if we want to do mailbox style updates with
> vrr since then we'd definitely do multiple commits per frame. Currently
> mailbox updates are only used by the legacy cursor, but we don't do
> vrr push for those.
> 
> Cc: Manasi Navare <manasi.d.navare@intel.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_crtc.c | 10 +++++++---
>  drivers/gpu/drm/i915/display/intel_vrr.c  | 12 ++++++++++++
>  drivers/gpu/drm/i915/display/intel_vrr.h  |  1 +
>  3 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
> index cf403be7736c..eb5444f90e77 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -470,10 +470,14 @@ void intel_pipe_update_start(struct intel_crtc_state *new_crtc_state)
>  	if (intel_crtc_needs_vblank_work(new_crtc_state))
>  		intel_crtc_vblank_work_init(new_crtc_state);
>  
> -	if (new_crtc_state->vrr.enable)
> -		vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
> -	else
> +	if (new_crtc_state->vrr.enable) {
> +		if (intel_vrr_is_push_sent(new_crtc_state))
> +			vblank_start = intel_vrr_vmin_vblank_start(new_crtc_state);

Actually if Push is sent then the vblank gets terminated at that point which falls between vmin and vmax so
not necessarily at Vmin but at anytime between vmin and vmax. Is it correct to calculate it based on vmin?

> +		else
> +			vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
> +	} else {
>  		vblank_start = intel_mode_vblank_start(adjusted_mode);
> +	}
>  
>  	/* FIXME needs to be calibrated sensibly */
>  	min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
> index c335b1dbafcf..db1c3902fc2d 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> @@ -193,6 +193,18 @@ void intel_vrr_send_push(const struct intel_crtc_state *crtc_state)
>  		       TRANS_PUSH_EN | TRANS_PUSH_SEND);
>  }
>  
> +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state)
> +{
> +	struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> +	struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> +	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> +
> +	if (!crtc_state->vrr.enable)
> +		return false;
> +
> +	return intel_de_read(dev_priv, TRANS_PUSH(cpu_transcoder)) & TRANS_PUSH_SEND;

But HW clears this bit after double buffer update. Is this a good inidcation to check the PUSH_SEND bit?

Manasi

> +}
> +
>  void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state)
>  {
>  	struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.h b/drivers/gpu/drm/i915/display/intel_vrr.h
> index 96f9c9c27ab9..1c2da572693d 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.h
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.h
> @@ -23,6 +23,7 @@ void intel_vrr_compute_config(struct intel_crtc_state *crtc_state,
>  void intel_vrr_enable(struct intel_encoder *encoder,
>  		      const struct intel_crtc_state *crtc_state);
>  void intel_vrr_send_push(const struct intel_crtc_state *crtc_state);
> +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state);
>  void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state);
>  void intel_vrr_get_config(struct intel_crtc *crtc,
>  			  struct intel_crtc_state *crtc_state);
> -- 
> 2.32.0
> 

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Do vblank evasion correctly if vrr push has already been sent

[Ville Syrjälä]

On Wed, Nov 17, 2021 at 01:10:13PM -0800, Navare, Manasi wrote:
> On Wed, Nov 17, 2021 at 08:31:02PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > Let's adjust the vblank evasion to account for the case where
> > a push has already been sent. In that case the vblank exit will start
> > at vmin vblank start (as opposed to vmax vblank start when no push
> > has been sent).
> > 
> > This should minimize the effects of the tiny race between sampling
> > the frame counter vs. intel_vrr_send_push() during the previous frame.
> > This will also be required if we want to do mailbox style updates with
> > vrr since then we'd definitely do multiple commits per frame. Currently
> > mailbox updates are only used by the legacy cursor, but we don't do
> > vrr push for those.
> > 
> > Cc: Manasi Navare <manasi.d.navare@intel.com>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/display/intel_crtc.c | 10 +++++++---
> >  drivers/gpu/drm/i915/display/intel_vrr.c  | 12 ++++++++++++
> >  drivers/gpu/drm/i915/display/intel_vrr.h  |  1 +
> >  3 files changed, 20 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
> > index cf403be7736c..eb5444f90e77 100644
> > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > @@ -470,10 +470,14 @@ void intel_pipe_update_start(struct intel_crtc_state *new_crtc_state)
> >  	if (intel_crtc_needs_vblank_work(new_crtc_state))
> >  		intel_crtc_vblank_work_init(new_crtc_state);
> >  
> > -	if (new_crtc_state->vrr.enable)
> > -		vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
> > -	else
> > +	if (new_crtc_state->vrr.enable) {
> > +		if (intel_vrr_is_push_sent(new_crtc_state))
> > +			vblank_start = intel_vrr_vmin_vblank_start(new_crtc_state);
> 
> Actually if Push is sent then the vblank gets terminated at that point which falls between vmin and vmax so
> not necessarily at Vmin but at anytime between vmin and vmax. Is it correct to calculate it based on vmin?

If you do a push between vmin and vmax then the vblank terminates
immediately and the PUSH_SEND bit gets cleared. The only way the bit
stays set is you set it after vmax/before vmin.

> 
> > +		else
> > +			vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
> > +	} else {
> >  		vblank_start = intel_mode_vblank_start(adjusted_mode);
> > +	}
> >  
> >  	/* FIXME needs to be calibrated sensibly */
> >  	min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
> > index c335b1dbafcf..db1c3902fc2d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> > @@ -193,6 +193,18 @@ void intel_vrr_send_push(const struct intel_crtc_state *crtc_state)
> >  		       TRANS_PUSH_EN | TRANS_PUSH_SEND);
> >  }
> >  
> > +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state)
> > +{
> > +	struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > +	struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > +	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > +
> > +	if (!crtc_state->vrr.enable)
> > +		return false;
> > +
> > +	return intel_de_read(dev_priv, TRANS_PUSH(cpu_transcoder)) & TRANS_PUSH_SEND;
> 
> But HW clears this bit after double buffer update. Is this a good inidcation to check the PUSH_SEND bit?
> 
> Manasi
> 
> > +}
> > +
> >  void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state)
> >  {
> >  	struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
> > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.h b/drivers/gpu/drm/i915/display/intel_vrr.h
> > index 96f9c9c27ab9..1c2da572693d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vrr.h
> > +++ b/drivers/gpu/drm/i915/display/intel_vrr.h
> > @@ -23,6 +23,7 @@ void intel_vrr_compute_config(struct intel_crtc_state *crtc_state,
> >  void intel_vrr_enable(struct intel_encoder *encoder,
> >  		      const struct intel_crtc_state *crtc_state);
> >  void intel_vrr_send_push(const struct intel_crtc_state *crtc_state);
> > +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state);
> >  void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state);
> >  void intel_vrr_get_config(struct intel_crtc *crtc,
> >  			  struct intel_crtc_state *crtc_state);
> > -- 
> > 2.32.0
> > 

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Do vblank evasion correctly if vrr push has already been sent

[Navare, Manasi]

On Wed, Nov 17, 2021 at 11:04:05PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 17, 2021 at 01:10:13PM -0800, Navare, Manasi wrote:
> > On Wed, Nov 17, 2021 at 08:31:02PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > 
> > > Let's adjust the vblank evasion to account for the case where
> > > a push has already been sent. In that case the vblank exit will start
> > > at vmin vblank start (as opposed to vmax vblank start when no push
> > > has been sent).
> > > 
> > > This should minimize the effects of the tiny race between sampling
> > > the frame counter vs. intel_vrr_send_push() during the previous frame.
> > > This will also be required if we want to do mailbox style updates with
> > > vrr since then we'd definitely do multiple commits per frame. Currently
> > > mailbox updates are only used by the legacy cursor, but we don't do
> > > vrr push for those.
> > > 
> > > Cc: Manasi Navare <manasi.d.navare@intel.com>
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_crtc.c | 10 +++++++---
> > >  drivers/gpu/drm/i915/display/intel_vrr.c  | 12 ++++++++++++
> > >  drivers/gpu/drm/i915/display/intel_vrr.h  |  1 +
> > >  3 files changed, 20 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > index cf403be7736c..eb5444f90e77 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > @@ -470,10 +470,14 @@ void intel_pipe_update_start(struct intel_crtc_state *new_crtc_state)
> > >  	if (intel_crtc_needs_vblank_work(new_crtc_state))
> > >  		intel_crtc_vblank_work_init(new_crtc_state);
> > >  
> > > -	if (new_crtc_state->vrr.enable)
> > > -		vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
> > > -	else
> > > +	if (new_crtc_state->vrr.enable) {
> > > +		if (intel_vrr_is_push_sent(new_crtc_state))
> > > +			vblank_start = intel_vrr_vmin_vblank_start(new_crtc_state);
> > 
> > Actually if Push is sent then the vblank gets terminated at that point which falls between vmin and vmax so
> > not necessarily at Vmin but at anytime between vmin and vmax. Is it correct to calculate it based on vmin?
> 
> If you do a push between vmin and vmax then the vblank terminates
> immediately and the PUSH_SEND bit gets cleared. The only way the bit
> stays set is you set it after vmax/before vmin.
>

The scenario where PUSH comes in during the active so that its before Vmin, then it will stay on until we hit vmin to
terminate the vblank.
But when we reach Vmax, the HW will terminate the vblank anyways, should we actually alter the code to not
allow any PUSH after Vmax?

Manasi
 
> > 
> > > +		else
> > > +			vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
> > > +	} else {
> > >  		vblank_start = intel_mode_vblank_start(adjusted_mode);
> > > +	}
> > >  
> > >  	/* FIXME needs to be calibrated sensibly */
> > >  	min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> > > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > index c335b1dbafcf..db1c3902fc2d 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > @@ -193,6 +193,18 @@ void intel_vrr_send_push(const struct intel_crtc_state *crtc_state)
> > >  		       TRANS_PUSH_EN | TRANS_PUSH_SEND);
> > >  }
> > >  
> > > +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state)
> > > +{
> > > +	struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > +	struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > +	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > > +
> > > +	if (!crtc_state->vrr.enable)
> > > +		return false;
> > > +
> > > +	return intel_de_read(dev_priv, TRANS_PUSH(cpu_transcoder)) & TRANS_PUSH_SEND;
> > 
> > But HW clears this bit after double buffer update. Is this a good inidcation to check the PUSH_SEND bit?
> > 
> > Manasi
> > 
> > > +}
> > > +
> > >  void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state)
> > >  {
> > >  	struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
> > > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.h b/drivers/gpu/drm/i915/display/intel_vrr.h
> > > index 96f9c9c27ab9..1c2da572693d 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_vrr.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_vrr.h
> > > @@ -23,6 +23,7 @@ void intel_vrr_compute_config(struct intel_crtc_state *crtc_state,
> > >  void intel_vrr_enable(struct intel_encoder *encoder,
> > >  		      const struct intel_crtc_state *crtc_state);
> > >  void intel_vrr_send_push(const struct intel_crtc_state *crtc_state);
> > > +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state);
> > >  void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state);
> > >  void intel_vrr_get_config(struct intel_crtc *crtc,
> > >  			  struct intel_crtc_state *crtc_state);
> > > -- 
> > > 2.32.0
> > > 
> 
> -- 
> Ville Syrjälä
> Intel

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Do vblank evasion correctly if vrr push has already been sent

[Navare, Manasi]

On Wed, Nov 17, 2021 at 03:09:45PM -0800, Navare, Manasi wrote:
> On Wed, Nov 17, 2021 at 11:04:05PM +0200, Ville Syrjälä wrote:
> > On Wed, Nov 17, 2021 at 01:10:13PM -0800, Navare, Manasi wrote:
> > > On Wed, Nov 17, 2021 at 08:31:02PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > 
> > > > Let's adjust the vblank evasion to account for the case where
> > > > a push has already been sent. In that case the vblank exit will start
> > > > at vmin vblank start (as opposed to vmax vblank start when no push
> > > > has been sent).
> > > > 
> > > > This should minimize the effects of the tiny race between sampling
> > > > the frame counter vs. intel_vrr_send_push() during the previous frame.
> > > > This will also be required if we want to do mailbox style updates with
> > > > vrr since then we'd definitely do multiple commits per frame. Currently
> > > > mailbox updates are only used by the legacy cursor, but we don't do
> > > > vrr push for those.
> > > > 
> > > > Cc: Manasi Navare <manasi.d.navare@intel.com>
> > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

I still want to see if PUSH send can be cleared if its coming after Vmax because then that
will affect the next frame that will always just terminate at Vmin. But we can continue that
discussion later. For this patch

Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>

Manasi

> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_crtc.c | 10 +++++++---
> > > >  drivers/gpu/drm/i915/display/intel_vrr.c  | 12 ++++++++++++
> > > >  drivers/gpu/drm/i915/display/intel_vrr.h  |  1 +
> > > >  3 files changed, 20 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > index cf403be7736c..eb5444f90e77 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > @@ -470,10 +470,14 @@ void intel_pipe_update_start(struct intel_crtc_state *new_crtc_state)
> > > >  	if (intel_crtc_needs_vblank_work(new_crtc_state))
> > > >  		intel_crtc_vblank_work_init(new_crtc_state);
> > > >  
> > > > -	if (new_crtc_state->vrr.enable)
> > > > -		vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
> > > > -	else
> > > > +	if (new_crtc_state->vrr.enable) {
> > > > +		if (intel_vrr_is_push_sent(new_crtc_state))
> > > > +			vblank_start = intel_vrr_vmin_vblank_start(new_crtc_state);
> > > 
> > > Actually if Push is sent then the vblank gets terminated at that point which falls between vmin and vmax so
> > > not necessarily at Vmin but at anytime between vmin and vmax. Is it correct to calculate it based on vmin?
> > 
> > If you do a push between vmin and vmax then the vblank terminates
> > immediately and the PUSH_SEND bit gets cleared. The only way the bit
> > stays set is you set it after vmax/before vmin.
> >
> 
> The scenario where PUSH comes in during the active so that its before Vmin, then it will stay on until we hit vmin to
> terminate the vblank.
> But when we reach Vmax, the HW will terminate the vblank anyways, should we actually alter the code to not
> allow any PUSH after Vmax?
> 
> Manasi
>  
> > > 
> > > > +		else
> > > > +			vblank_start = intel_vrr_vmax_vblank_start(new_crtc_state);
> > > > +	} else {
> > > >  		vblank_start = intel_mode_vblank_start(adjusted_mode);
> > > > +	}
> > > >  
> > > >  	/* FIXME needs to be calibrated sensibly */
> > > >  	min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > > index c335b1dbafcf..db1c3902fc2d 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> > > > @@ -193,6 +193,18 @@ void intel_vrr_send_push(const struct intel_crtc_state *crtc_state)
> > > >  		       TRANS_PUSH_EN | TRANS_PUSH_SEND);
> > > >  }
> > > >  
> > > > +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state)
> > > > +{
> > > > +	struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > > +	struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > > +	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > > > +
> > > > +	if (!crtc_state->vrr.enable)
> > > > +		return false;
> > > > +
> > > > +	return intel_de_read(dev_priv, TRANS_PUSH(cpu_transcoder)) & TRANS_PUSH_SEND;
> > > 
> > > But HW clears this bit after double buffer update. Is this a good inidcation to check the PUSH_SEND bit?
> > > 
> > > Manasi
> > > 
> > > > +}
> > > > +
> > > >  void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state)
> > > >  {
> > > >  	struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_vrr.h b/drivers/gpu/drm/i915/display/intel_vrr.h
> > > > index 96f9c9c27ab9..1c2da572693d 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_vrr.h
> > > > +++ b/drivers/gpu/drm/i915/display/intel_vrr.h
> > > > @@ -23,6 +23,7 @@ void intel_vrr_compute_config(struct intel_crtc_state *crtc_state,
> > > >  void intel_vrr_enable(struct intel_encoder *encoder,
> > > >  		      const struct intel_crtc_state *crtc_state);
> > > >  void intel_vrr_send_push(const struct intel_crtc_state *crtc_state);
> > > > +bool intel_vrr_is_push_sent(const struct intel_crtc_state *crtc_state);
> > > >  void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state);
> > > >  void intel_vrr_get_config(struct intel_crtc *crtc,
> > > >  			  struct intel_crtc_state *crtc_state);
> > > > -- 
> > > > 2.32.0
> > > > 
> > 
> > -- 
> > Ville Syrjälä
> > Intel

[Intel-gfx] [PATCH 3/3] drm/i915: Fix framestart_delay commens in VRR code

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

Since I originally wrote these comments we decided to change our
definition of framestart_delay from 0-3 to 1-4. Adjust the comments
to match that new convention. The actual code was adjusted already.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/display/intel_vrr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
index db1c3902fc2d..139e8936edc5 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.c
+++ b/drivers/gpu/drm/i915/display/intel_vrr.c
@@ -60,7 +60,7 @@ intel_vrr_check_modeset(struct intel_atomic_state *state)
  * Between those two points the vblank exit starts (and hence registers get
  * latched) ASAP after a push is sent.
  *
- * framestart_delay is programmable 0-3.
+ * framestart_delay is programmable 1-4.
  */
 static int intel_vrr_vblank_exit_length(const struct intel_crtc_state *crtc_state)
 {
@@ -138,13 +138,13 @@ intel_vrr_compute_config(struct intel_crtc_state *crtc_state,
 			i915->window2_delay;
 	else
 		/*
-		 * FIXME: s/4/framestart_delay+1/ to get consistent
+		 * FIXME: s/4/framestart_delay/ to get consistent
 		 * earliest/latest points for register latching regardless
 		 * of the framestart_delay used?
 		 *
 		 * FIXME: this really needs the extra scanline to provide consistent
 		 * behaviour for all framestart_delay values. Otherwise with
-		 * framestart_delay==3 we will end up extending the min vblank by
+		 * framestart_delay==4 we will end up extending the min vblank by
 		 * one extra line.
 		 */
 		crtc_state->vrr.pipeline_full =
-- 
2.32.0

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix framestart_delay commens in VRR code

[Navare, Manasi]

On Wed, Nov 17, 2021 at 08:31:03PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Since I originally wrote these comments we decided to change our
> definition of framestart_delay from 0-3 to 1-4. Adjust the comments
> to match that new convention. The actual code was adjusted already.
> 
> Cc: Manasi Navare <manasi.d.navare@intel.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_vrr.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c
> index db1c3902fc2d..139e8936edc5 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> @@ -60,7 +60,7 @@ intel_vrr_check_modeset(struct intel_atomic_state *state)
>   * Between those two points the vblank exit starts (and hence registers get
>   * latched) ASAP after a push is sent.
>   *
> - * framestart_delay is programmable 0-3.
> + * framestart_delay is programmable 1-4.
>   */
>  static int intel_vrr_vblank_exit_length(const struct intel_crtc_state *crtc_state)
>  {
> @@ -138,13 +138,13 @@ intel_vrr_compute_config(struct intel_crtc_state *crtc_state,
>  			i915->window2_delay;
>  	else
>  		/*
> -		 * FIXME: s/4/framestart_delay+1/ to get consistent
> +		 * FIXME: s/4/framestart_delay/ to get consistent
>  		 * earliest/latest points for register latching regardless
>  		 * of the framestart_delay used?
>  		 *
>  		 * FIXME: this really needs the extra scanline to provide consistent
>  		 * behaviour for all framestart_delay values. Otherwise with
> -		 * framestart_delay==3 we will end up extending the min vblank by
> +		 * framestart_delay==4 we will end up extending the min vblank by
>  		 * one extra line.
>  		 */
>  		crtc_state->vrr.pipeline_full =
> -- 
> 2.32.0
> 

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Move vrr push after the frame counter sampling again

[Navare, Manasi]

On Wed, Nov 17, 2021 at 08:31:01PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Moving the vrr push to happen before sampling the frame counter
> was wrong. If we are already in vblank when the push is sent
> the vblank exit will start immediately which causes the sampled
> frame counter to correspond to the next frame instead of the current
> frame.
> 
> So put things back into the original order (except we should
> keep the vrr push within the irq disable section to avoid
> pointless irq related delays here).
> 
> We'll just have to accept the tiny race that exists between
> sampling the frame counter vs. vrr push. And let's at least
> document said race properly in a comment.
> 
> I suppose we could try to minimize the race by sampling the frame
> counter just before sending the push, but that would require
> changing drm_crtc_arm_vblank_event() to accept a caller provided
> vblank counter value, so leave it be for now. Another thing we
> could do is change the vblank evasion to account for the case
> where a push was already sent. That would anyway be required
> for mailbox style updates. Currently mailbox updates are only
> used by the legacy cursor, but we don't do a vrr push for those.
> 
> Cc: Manasi Navare <manasi.d.navare@intel.com>
> Fixes: 6f9976bd1310 ("drm/i915: Do vrr push before sampling the frame counter")
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

The original order was to send push after enabling IRQs but I think it makes
sense to send push just before enabling IRQs so avoid the vblank
termination getting delayed due to IRQs

Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_crtc.c | 19 ++++++++++++++++---
>  1 file changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
> index f09df2cf052b..cf403be7736c 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -610,9 +610,6 @@ void intel_pipe_update_end(struct intel_crtc_state *new_crtc_state)
>  
>  	trace_intel_pipe_update_end(crtc, end_vbl_count, scanline_end);
>  
> -	/* Send VRR Push to terminate Vblank */
> -	intel_vrr_send_push(new_crtc_state);
> -
>  	/*
>  	 * Incase of mipi dsi command mode, we need to set frame update
>  	 * request for every commit.
> @@ -641,6 +638,22 @@ void intel_pipe_update_end(struct intel_crtc_state *new_crtc_state)
>  		new_crtc_state->uapi.event = NULL;
>  	}
>  
> +	/*
> +	 * Send VRR Push to terminate Vblank. If we are already in vblank
> +	 * this has to be done _after_ sampling the frame counter, as
> +	 * otherwise the push would immediately terminate the vblank and
> +	 * the sampled frame counter would correspond to the next frame
> +	 * instead of the current frame.
> +	 *
> +	 * There is a tiny race here (iff vblank evasion failed us) where
> +	 * we might sample the frame counter just before vmax vblank start
> +	 * but the push would be sent just after it. That would cause the
> +	 * push to affect the next frame instead of the current frame,
> +	 * which would cause the next frame to terminate already at vmin
> +	 * vblank start instead of vmax vblank start.
> +	 */
> +	intel_vrr_send_push(new_crtc_state);
> +
>  	local_irq_enable();
>  
>  	if (intel_vgpu_active(dev_priv))
> -- 
> 2.32.0
> 

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Move vrr push after the frame counter sampling again

[Patchwork]

[-- Attachment #1: Type: text/plain, Size: 7331 bytes --]

== Series Details ==

Series: series starting with [1/3] drm/i915: Move vrr push after the frame counter sampling again
URL   : https://patchwork.freedesktop.org/series/97037/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10896 -> Patchwork_21623
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_21623 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_21623, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/index.html

Participating hosts (40 -> 34)
------------------------------

  Additional (1): fi-tgl-1115g4 
  Missing    (7): bat-dg1-6 fi-hsw-4200u fi-icl-u2 fi-bsw-cyan fi-ctg-p8600 bat-jsl-2 bat-jsl-1 

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_21623:

### IGT changes ###

#### Possible regressions ####

  * igt@gem_lmem_swapping@verify-random:
    - fi-tgl-1115g4:      NOTRUN -> [SKIP][1] +3 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-1115g4/igt@gem_lmem_swapping@verify-random.html

  
Known issues
------------

  Here are the changes found in Patchwork_21623 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@amdgpu/amd_basic@cs-gfx:
    - fi-rkl-guc:         NOTRUN -> [SKIP][2] ([fdo#109315]) +17 similar issues
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-rkl-guc/igt@amdgpu/amd_basic@cs-gfx.html

  * igt@amdgpu/amd_basic@query-info:
    - fi-tgl-1115g4:      NOTRUN -> [SKIP][3] ([fdo#109315])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-1115g4/igt@amdgpu/amd_basic@query-info.html

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
    - fi-tgl-1115g4:      NOTRUN -> [SKIP][4] ([fdo#109315] / [i915#2575]) +16 similar issues
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-1115g4/igt@amdgpu/amd_cs_nop@nop-gfx0.html

  * igt@gem_exec_suspend@basic-s0:
    - fi-tgl-u2:          [PASS][5] -> [FAIL][6] ([i915#1888])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-tgl-u2/igt@gem_exec_suspend@basic-s0.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-u2/igt@gem_exec_suspend@basic-s0.html

  * igt@gem_huc_copy@huc-copy:
    - fi-tgl-1115g4:      NOTRUN -> [SKIP][7] ([i915#2190])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-1115g4/igt@gem_huc_copy@huc-copy.html

  * igt@i915_pm_backlight@basic-brightness:
    - fi-tgl-1115g4:      NOTRUN -> [SKIP][8] ([i915#1155])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-1115g4/igt@i915_pm_backlight@basic-brightness.html

  * igt@i915_selftest@live@gt_heartbeat:
    - fi-cfl-8109u:       [PASS][9] -> [DMESG-FAIL][10] ([i915#541])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-tgl-1115g4:      NOTRUN -> [SKIP][11] ([fdo#111827]) +8 similar issues
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-1115g4/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
    - fi-tgl-1115g4:      NOTRUN -> [SKIP][12] ([i915#4103]) +1 similar issue
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-1115g4/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
    - fi-tgl-1115g4:      NOTRUN -> [SKIP][13] ([fdo#109285])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-1115g4/igt@kms_force_connector_basic@force-load-detect.html

  * igt@kms_psr@primary_mmap_gtt:
    - fi-tgl-1115g4:      NOTRUN -> [SKIP][14] ([i915#1072]) +3 similar issues
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html

  * igt@prime_vgem@basic-userptr:
    - fi-tgl-1115g4:      NOTRUN -> [SKIP][15] ([i915#3301])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-tgl-1115g4/igt@prime_vgem@basic-userptr.html

  
#### Possible fixes ####

  * igt@i915_selftest@live@evict:
    - fi-kbl-soraka:      [DMESG-WARN][16] -> [PASS][17]
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-kbl-soraka/igt@i915_selftest@live@evict.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-kbl-soraka/igt@i915_selftest@live@evict.html

  * igt@i915_selftest@live@gt_engines:
    - fi-rkl-guc:         [DMESG-FAIL][18] -> [PASS][19]
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html

  * igt@kms_frontbuffer_tracking@basic:
    - fi-cml-u2:          [DMESG-WARN][20] ([i915#4269]) -> [PASS][21]
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10896/fi-cml-u2/igt@kms_frontbuffer_tracking@basic.html
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/fi-cml-u2/igt@kms_frontbuffer_tracking@basic.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
  [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541


Build changes
-------------

  * Linux: CI_DRM_10896 -> Patchwork_21623

  CI-20190529: 20190529
  CI_DRM_10896: bf11e5f354ac51635d032893d80a1d0015d277dc @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6283: a2cd90a7c24bb7a4c19ca74c75ed8c950820dee2 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21623: d0a88b4bf6c3d115679dae995605650f86288037 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

d0a88b4bf6c3 drm/i915: Fix framestart_delay commens in VRR code
1f1ceabe1028 drm/i915: Do vblank evasion correctly if vrr push has already been sent
1f8218ddb558 drm/i915: Move vrr push after the frame counter sampling again

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21623/index.html

[-- Attachment #2: Type: text/html, Size: 8446 bytes --]