Re: [PATCH 5/8] drm/i915: Prepare for atomic plane helpers (v2)

[Daniel Vetter <daniel@ffwll.ch>]

On Thu, Nov 13, 2014 at 05:23:05PM -0800, Matt Roper wrote:
> On Thu, Nov 13, 2014 at 02:51:32PM -0800, Matt Roper wrote:
> > Add the new driver entrypoints that will be called by the atomic plane
> > helpers.
> > 
> > This patch does not actually switch over to the new plane helpers yet,
> > so there should be no functional change here.  Also note that although
> > plane programming was already split into check/prepare/commit steps,
> > some of the semantics of those individual functions will need to change
> > slightly when we do make the jump so that they match the behavior the
> > plane helpers expect.
> > 
> > v2:
> >  - Renamed file from intel_atomic.c to intel_atomic_plane.c (Daniel)
> >  - Fix a copy/paste comment mistake (Bob)
> > 
> > Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> 
> Actually, I don't think this is quite ready to go yet.  I must have had
> too much debug spam turned on before and missed the important messages
> in the kernel log, but it looks like we're still calling something that
> can sleep (in the frontbuffer tracking code?) while irqs are disabled
> for vblank evasion.

Yeah the frontbuffer tracking code will sleep since it can grab mutexes.

We also want to eventually grow async support out of this, so I think the
best approach might be to simply use frontbuffer_flip_prepare/complete
around the entire sequence. Well the important part is that we call
prepare before we start waiting for outstanding rendering and complete
after pipe_update_end.

Since this loops over abstract plane objects I think we need to store the
correct frontbuffer tracking bit somewhere in intel_plane so that we can
get at them.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx