• Nicholas Kazlauskas's avatar
    drm/amd/display: Defer cursor lock until after VUPDATE · 31ecebee
    Nicholas Kazlauskas authored
    [Why]
    We dropped the delay after changed the cursor functions locking the
    entire pipe to locking just the CURSOR registers to fix page flip
    stuttering - this introduced cursor stuttering instead, and an underflow
    issue.
    
    The cursor update can be delayed indefinitely if the cursor update
    repeatedly happens right around VUPDATE.
    
    The underflow issue can happen if we do a viewport update on a pipe
    on the same frame where a cursor update happens around VUPDATE - the
    old cursor registers are retained which can be in an invalid position.
    
    This can cause a pipe hang and indefinite underflow.
    
    [How]
    The complex, ideal solution to the problem would be a software
    triple buffering mechanism from the DM layer to program only one cursor
    update per frame just before VUPDATE.
    
    The simple workaround until we have that infrastructure in place is
    this change - bring back the delay until VUPDATE before locking, but
    with some corrections to the calculations.
    
    This didn't work for all timings before because the calculation for
    VUPDATE was wrong - it was using the offset from VSTARTUP instead and
    didn't correctly handle the case where VUPDATE could be in the back
    porch.
    
    Add a new hardware sequencer function to use the existing helper to
    calculate the real VUPDATE start and VUPDATE end - VUPDATE can last
    multiple lines after all.
    
    Change the udelay to incorporate the width of VUPDATE as well.
    Signed-off-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Reviewed-by: default avatarAric Cyr <Aric.Cyr@amd.com>
    Acked-by: default avatarRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
    31ecebee
dcn10_init.c 5.16 KB