git: drm/i915: drm/i915: Ignore SURFLIVE and flip counter when the GPU gets reset

[Francois Tigeot]

commit 69975c1d987d2de08ade3a8ab65f792a950987ed
Author: François Tigeot <ftigeot at wolfpond.org>
Date:   Sun Sep 13 13:21:42 2015 +0200

    drm/i915: drm/i915: Ignore SURFLIVE and flip counter when the GPU gets reset
    
    This is commit 7cb9a79e3ee6e414d7f413cd1785d630ace9a1b0 from Linux 3.17.8
    Original author: Ville Syrjälä <ville.syrjala at linux.intel.com>
    0riginal commit message:
    
    commit bdfa7542d40e6251c232a802231b37116bd31b11 upstream.
    
    During a GPU reset we need to get pending page flip cleared out
    since the ring contents are gone and flip will never complete
    on its own. This used to work until the mmio vs. CS flip race
    detection came about. That piece of code is looking for a
    specific surface address in the SURFLIVE register, but as
    a flip to that address may never happen the check may never
    pass. So we should just skip the SURFLIVE and flip counter
    checks when the GPU gets reset.
    
    intel_display_handle_reset() tries to effectively complete
    the flip anyway by calling .update_primary_plane(). But that
    may not satisfy the conditions of the mmio vs. CS race
    detection since there's no guarantee that a modeset didn't
    sneak in between the GPU reset and intel_display_handle_reset().
    Such a modeset will not wait for pending flips due to the ongoing GPU
    reset, and then the primary plane updates performed by
    intel_display_handle_reset() will already use the new surface
    address, and thus the surface address the flip is waiting for
    might never appear in SURFLIVE. The result is that the flip
    will never complete and attempts to perform further page flips
    will fail with -EBUSY.
    
    During the GPU reset intel_crtc_has_pending_flip() will return
    false regardless, so the deadlock with a modeset vs. the error
    work acquiring crtc->mutex was avoided. And the reset_counter
    check in intel_crtc_has_pending_flip() actually made this bug
    even less severe since it allowed normal modesets to go through
    even though there's a pending flip.
    
    This is a regression introduced by me here:
     commit 75f7f3ec600524c9544cc31695155f1a9ddbe1d9
     Author: Ville Syrjälä <ville.syrjala at linux.intel.com>
     Date:   Tue Apr 15 21:41:34 2014 +0300
    
        drm/i915: Fix mmio vs. CS flip race on ILK+
    
    Testcase: igt/kms_flip/flip-vs-panning-vs-hang
    Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
    Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
    Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
    Signed-off-by: Jani Nikula <jani.nikula at intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>

Summary of changes:
 sys/dev/drm/i915/intel_display.c | 4 ++++
 1 file changed, 4 insertions(+)

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/69975c1d987d2de08ade3a8ab65f792a950987ed


-- 
DragonFly BSD source repository