On Mon, Dec 01, 2014 at 10:29:04AM +0200, Ander Conselvan de Oliveira wrote:
> On 11/24/2014 09:53 PM, Matt Roper wrote:
...
> >-static int
> >-intel_prepare_sprite_plane(struct drm_plane *plane,
> >- struct intel_plane_state *state)
> >-{
> >- struct drm_device *dev = plane->dev;
> >- struct drm_crtc *crtc = state->base.crtc;
> >- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> >- struct intel_plane *intel_plane = to_intel_plane(plane);
> >- enum pipe pipe = intel_crtc->pipe;
> >- struct drm_framebuffer *fb = state->base.fb;
> >- struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> >- struct drm_i915_gem_object *old_obj = intel_plane->obj;
>
> This used to look at intel_plane->obj, but the new unified prepare
> function uses the value of intel_plane->base.fb, which is not
> updated in intel_commit_sprite_plane().
>
> Ander
I think this should be okay (same for the cursor case you noted in a
previous patch) because the DRM core updates drm_plane->fb for us in
__setplane_internal() after the driver's update handler succeeds.
Updating drm_plane->fb inside the driver's commit function should only
be necessary if we then use that new value before returning back to the
DRM core. In the case you note above, we're looking at the value which
was updated by the DRM core following the previous sprite update.
Matt
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
