[Intel-gfx] [PATCH] drm/i915: Treat resetting of the current framebuffer as a no-op

[Daniel Vetter]

On Thu, May 23, 2013 at 01:57:17PM +0100, Chris Wilson wrote:
> If none of the CRTC parameters change along with the framebuffer, we can
> forgo rewriting the register and waiting for a vblank. There are a few
> calls made by the display managers as they start up which tend to end up
> performing no-ops on the current CRTC settings.
> 
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>

Makes sense. Queued for -next, thanks for the patch. Now the only things
left (besides beating fastboot into good shape) is to cache the edids a
bit and we've (hopefully) killed all kms stalls at startup ...
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_display.c |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 981549c..f4450f1 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2286,6 +2286,11 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
>  		return -EINVAL;
>  	}
>  
> +	if (fb == crtc->fb && crtc->x == x && crtc->y == y) {
> +		DRM_DEBUG_KMS("skipping reset of current fb");
> +		return 0;
> +	}
> +
>  	mutex_lock(&dev->struct_mutex);
>  	ret = intel_pin_and_fence_fb_obj(dev,
>  					 to_intel_framebuffer(fb)->obj,
> -- 
> 1.7.10.4
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch