Jerome Glisse 3b7a2b24ea drm/radeon: rework fence handling, drop fence list v7
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: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Christian König <deathsimple@vodafone.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-09 17:22:19 +01:00
..
2012-05-03 17:16:52 -07:00
2012-04-20 11:31:00 -07:00
2012-03-19 09:37:11 +00:00
2012-03-27 16:03:32 -07:00
2012-04-27 10:46:45 +08:00
2012-04-12 15:36:33 -07:00
2012-05-03 01:42:55 -04:00
2012-05-07 14:02:14 +02:00
2012-03-17 01:41:43 -07:00
2012-03-30 00:09:17 -07:00
2012-05-02 13:47:49 -07:00
2012-04-18 13:15:51 -07:00
2012-05-07 14:02:14 +02:00