[Intel-gfx] [PATCH 0/4] More nuclear pageflip

[Matt Roper]

On Sat, Jan 31, 2015 at 10:35:32AM +0100, Daniel Vetter wrote:
> On Fri, Jan 30, 2015 at 04:22:35PM -0800, Matt Roper wrote:
> > The first two patches here were already posted earlier this week; they allow
> > our legacy plane updates to make use of the main atomic helpers rather than the
> > transitional atomic helpers.  This shouldn't have any functional change, but it
> > will cause us to exercise the full atomic pipeline rather than just the plane
> > subset of it.
> > 
> > The third patch is the interesting one; it allows us to handle nuclear pageflip
> > requests in a non-blocking manner and deliver a uevent upon completion.  This
> > is important functionality for compositors since it allows them to request that
> > the kernel perform a flip, then continue on doing other work while they wait
> > for the flip to actually happen.
> > 
> > The final patch here switches our legacy pageflip ioctl to use the atomic
> > helper (thus exercising the new asynchronous support added in patch #3).
> > Removing the i915-specific pageflip handling should allow us to drop a bunch of
> > our display code; I've been somewhat conservative in my code removal for now
> > (just enough to get rid of the 'function unused' compiler warnings); we can do
> > further cleanup of code that relates to the legacy pageflip pipeline in a
> > future patchset.
> 
> Our current mmio flip doesn't work on gen4 and earlier because the flip
> completion event generation only works with MI_ flips. So I think we need
> to (at least for now) keep the legacy flip code around and wired up for
> those platforms.
> 
> But we need to redo the flip completion anyway (and probably just key off
> the next vblank interrupt) since if you'd do an atomic flip with just
> sprites the event stuff wont work on any platform. Once we have that we
> can then also roll out the legacy-pageflip-on-atomic for older platforms.
> -Daniel

Hmm, my code at the moment sends the completion event to userspace and
marks the CRTC as no longer having a flip pending after
drm_atomic_helper_wait_for_vblanks(dev, state) call, which probably
works when we're actually updating the framebuffer, but I guess that
will send the uevent too early in cases where the fb doesn't change
(since we already made a point of optimizing out that unnecessary vblank
wait).

So maybe I should just get the "schedule stuff for future vblank"
mechanism done that I already had on my plate for the watermark stuff,
and then use that to send the uevent once the next vblank following the
commit happens.

It occurs to me that I probably need to take a look at all the i915
hangcheck/recovery stuff too; I haven't paid much attention to how that
works, but I'm guessing it probably needs to be updated a bit now as
well.


Matt

> 
> > 
> > Matt Roper (4):
> >   drm/i915: Keep plane->state updated on pageflip
> >   drm/i915: Switch planes from transitional helpers to full atomic
> >     helpers
> >   drm/i915: Enable asynchronous nuclear flips
> >   drm/i915: Use atomic helper for pageflips
> > 
> >  drivers/gpu/drm/i915/i915_drv.h      |   9 +-
> >  drivers/gpu/drm/i915/i915_params.c   |   5 -
> >  drivers/gpu/drm/i915/intel_atomic.c  | 162 ++++++--
> >  drivers/gpu/drm/i915/intel_display.c | 716 +----------------------------------
> >  drivers/gpu/drm/i915/intel_drv.h     |   8 +
> >  drivers/gpu/drm/i915/intel_lrc.c     |   3 +-
> >  6 files changed, 155 insertions(+), 748 deletions(-)
> > 
> > -- 
> > 1.8.5.1
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx