[Intel-gfx] [PATCH 5/8] drm/i915: Prepare for atomic plane helpers (v2)
Daniel Vetter
daniel at ffwll.ch
Fri Nov 14 08:48:25 CET 2014
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 at 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
More information about the Intel-gfx
mailing list