drm/i915: Push i915_sw_fence_wait into the nonblocking atomic commit
authorDaniel Vetter <daniel.vetter@ffwll.ch>
Tue, 8 Aug 2017 08:08:27 +0000 (10:08 +0200)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Mon, 14 Aug 2017 15:03:11 +0000 (17:03 +0200)
commit42b062b0d9463557966766940791548313df6b55
treee32607d49a14b845fec9700c97f1066fe09e1dfd
parent97154ec242c14f646a3ab3b4da8f838d197f300d
drm/i915: Push i915_sw_fence_wait into the nonblocking atomic commit

Blocking in a worker is ok, that's what the unbound_wq is for. And it
unifies the paths between the blocking and nonblocking commit, giving
me just one path where I have to implement the deadlock avoidance
trickery in the next patch.

I first tried to implement the following patch without this rework, but
force-completing i915_sw_fence creates some serious challenges around
properly cleaning things up. So wasn't a feasible short-term approach.
Another approach would be to simple keep track of all pending atomic
commit work items and manually queue them from the reset code. With the
caveat that double-queue in case we race with the i915_sw_fence must be
avoided. Given all that, taking the cost of a double schedule in atomic
for the short-term fix is the best approach, but can be changed in the future of course.

v2: Amend commit message (Chris).

v3: Add comment explaining why we do nothing in the sw_fence complete
callback (Michel).

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v2)
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170808080828.23650-2-daniel.vetter@ffwll.ch
drivers/gpu/drm/i915/intel_display.c