Skip to content
  • Jerome Glisse's avatar
    drm/radeon: rework fence handling, drop fence list v7 · 3b7a2b24
    Jerome Glisse authored
    
    
    Using 64bits fence sequence we can directly compare sequence
    number to know if a fence is signaled or not. Thus the fence
    list became useless, so does the fence lock that mainly
    protected the fence list.
    
    Things like ring.ready are no longer behind a lock, this should
    be ok as ring.ready is initialized once and will only change
    when facing lockup. Worst case is that we return an -EBUSY just
    after a successfull GPU reset, or we go into wait state instead
    of returning -EBUSY (thus delaying reporting -EBUSY to fence
    wait caller).
    
    v2: Remove left over comment, force using writeback on cayman and
        newer, thus not having to suffer from possibly scratch reg
        exhaustion
    v3: Rebase on top of change to uint64 fence patch
    v4: Change DCE5 test to force write back on cayman and newer but
        also any APU such as PALM or SUMO family
    v5: Rebase on top of new uint64 fence patch
    v6: Just break if seq doesn't change any more. Use radeon_fence
        prefix for all function names. Even if it's now highly optimized,
        try avoiding polling to often.
    v7: We should never poll the last_seq from the hardware without
        waking the sleeping threads, otherwise we might lose events.
    
    Signed-off-by: default avatarJerome Glisse <jglisse@redhat.com>
    Signed-off-by: default avatarChristian König <deathsimple@vodafone.de>
    Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
    3b7a2b24