[Intel-gfx] [PATCH 10/10] drm/i915: Make all plane disables use 'update_plane' (v5)

Daniel Vetter daniel at ffwll.ch
Fri Dec 5 12:31:55 PST 2014


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 at intel.com>
> 
> 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 at intel.com>
> > Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira at intel.com>

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



More information about the Intel-gfx mailing list