On Fri, Dec 05, 2014 at 10:15:07AM +0200, Ander Conselvan de Oliveira wrote: > Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@xxxxxxxxx> > > On 12/04/2014 08:27 PM, Matt Roper wrote: > > If we extend the commit_plane handlers for each plane type to be able to > > handle fb=0, then we can easily implement plane disable via the > > update_plane handler. The cursor plane already works this way, and this > > is the direction we need to go to integrate with the atomic plane > > handler. We can now kill off the type-specific disable functions, as > > well as the redundant intel_plane_disable() (not to be confused with > > intel_disable_plane()). > > > > Note that prepare_plane_fb() only gets called as part of update_plane > > when fb!=NULL (by design, to match the semantics of the atomic plane > > helpers); this means that our commit_plane handlers need to handle the > > frontbuffer tracking for the disable case, even though they don't handle > > it for normal updates. > > > > v2: > > - Change BUG_ON to WARN_ON (Ander/Daniel) > > > > v3: > > - Drop unnecessary plane->crtc check since a previous patch to plane > > update ensures that plane->crtc will always be non-NULL, even for > > disable calls that might pass NULL from userspace. (Ander) > > - Drop a s/crtc/plane->crtc/ hunk that was unnecessary. (Ander) > > > > v4: > > - Fix missing whitespace (Ander) > > > > v5: > > - Use state's crtc rather than plane's crtc in > > intel_check_primary_plane(). plane->crtc could be NULL, but we've > > already fixed up state->crtc to ensure it's non-NULL (even if > > userspace passed it as NULL during a disable call). (Ander) > > > > Signed-off-by: Matt Roper <matthew.d.roper@xxxxxxxxx> > > Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@xxxxxxxxx> Ok, merged all 10 patches to dinq, thanks. There was a minor conflict in patch 8 due to the slight changes in patch 7, but nothing big really. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
