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@xxxxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
