Re: [PATCH 2/2] drm/i915: Complain if we take too long under vblank evasion.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 28, 2017 at 03:28:48PM +0100, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
> ---
>  drivers/gpu/drm/i915/intel_sprite.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
> index 27e0752d1578..375ca91b308c 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -65,6 +65,8 @@ int intel_usecs_to_scanlines(const struct drm_display_mode *adjusted_mode,
>  			    1000 * adjusted_mode->crtc_htotal);
>  }
>  
> +#define VBLANK_EVASION_TIME_US 100
> +
>  /**
>   * intel_pipe_update_start() - start update of a set of display registers
>   * @crtc: the crtc of which the registers are going to be updated
> @@ -92,7 +94,8 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
>  		vblank_start = DIV_ROUND_UP(vblank_start, 2);
>  
>  	/* FIXME needs to be calibrated sensibly */
> -	min = vblank_start - intel_usecs_to_scanlines(adjusted_mode, 100);
> +	min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> +						      VBLANK_EVASION_TIME_US);
>  	max = vblank_start - 1;
>  
>  	local_irq_disable();
> @@ -191,7 +194,12 @@ void intel_pipe_update_end(struct intel_crtc *crtc, struct intel_flip_work *work
>  			  ktime_us_delta(end_vbl_time, crtc->debug.start_vbl_time),
>  			  crtc->debug.min_vbl, crtc->debug.max_vbl,
>  			  crtc->debug.scanline_start, scanline_end);
> -	}
> +	} else if (ktime_us_delta(end_vbl_time, crtc->debug.start_vbl_time) >
> +		   VBLANK_EVASION_TIME_US)
> +		DRM_WARN("Atomic update on pipe (%c) took %lld us, max time under evasion is %u us\n",
> +			 pipe_name(pipe),
> +			 ktime_us_delta(end_vbl_time, crtc->debug.start_vbl_time),
> +			 VBLANK_EVASION_TIME_US);

Hmm. Yeah this should make it very likely that we'll catch any
potential fails even when they don't happen to hit the actual critical
section. Hopefully it won't result in massive amounts of noise. One way
to find out ;)

Reviewed-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>

>  }
>  
>  static void
> -- 
> 2.7.4
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux