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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
