[Intel-gfx] [PATCH] drm/i915: Introduce accurate frontbuffer tracking

[Chris Wilson]

On Wed, Jun 18, 2014 at 03:01:25PM +0200, Daniel Vetter wrote:
> +void i915_gem_update_fb_bits(struct drm_i915_gem_object *old,
> +			     struct drm_i915_gem_object *new,
> +			     unsigned frontbuffer_bits);
> +

Time to be a nuisance:

i915_gem_object_track_fb()

The key part is that is operates on the object. The other is just to try
and shorten the name as compensation.


> @@ -1062,6 +1065,7 @@ intel_disable_plane(struct drm_plane *plane)
>  	struct drm_device *dev = plane->dev;
>  	struct intel_plane *intel_plane = to_intel_plane(plane);
>  	struct intel_crtc *intel_crtc;
> +	enum pipe pipe;
>  
>  	if (!plane->fb)
>  		return 0;
> @@ -1070,6 +1074,7 @@ intel_disable_plane(struct drm_plane *plane)
>  		return -EINVAL;
>  
>  	intel_crtc = to_intel_crtc(plane->crtc);
> +	pipe = intel_crtc->pipe;
>  
>  	if (intel_crtc->active) {
>  		bool primary_was_enabled = intel_crtc->primary_enabled;
> @@ -1088,6 +1093,8 @@ intel_disable_plane(struct drm_plane *plane)
>  
>  		mutex_lock(&dev->struct_mutex);
>  		intel_unpin_fb_obj(intel_plane->obj);
> +		i915_gem_update_fb_bits(intel_plane->obj, NULL,
> +					INTEL_FRONTBUFFER_SPRITE(pipe));

Introducing a local here for a one off, or was checkpatch in an angry
mood with INTEL_FRONTBUFFER_SPRITE(intel_crtc->pipe) ?

That's all I spotted, the logic looks fine. But just remind me,
i915_gem_object_track_fb() did do a lockdep_assert_held(&dev->struct_mutex)?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre