1. 09 May, 2012 4 commits
    • 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
    • Jerome Glisse's avatar
      drm/radeon: convert fence to uint64_t v4 · bb635567
      Jerome Glisse authored
      
      
      This convert fence to use uint64_t sequence number intention is
      to use the fact that uin64_t is big enough that we don't need to
      care about wrap around.
      
      Tested with and without writeback using 0xFFFFF000 as initial
      fence sequence and thus allowing to test the wrap around from
      32bits to 64bits.
      
      v2: Add comment about possible race btw CPU & GPU, add comment
          stressing that we need 2 dword aligned for R600_WB_EVENT_OFFSET
          Read fence sequenc in reverse order of GPU write them so we
          mitigate the race btw CPU and GPU.
      
      v3: Drop the need for ring to emit the 64bits fence, and just have
          each ring emit the lower 32bits of the fence sequence. We
          handle the wrap over 32bits in fence_process.
      
      v4: Just a small optimization: Don't reread the last_seq value
          if loop restarts, since we already know its value anyway.
          Also start at zero not one for seq value and use pre instead
          of post increment in emmit, otherwise wait_empty will deadlock.
      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>
      bb635567
    • Christian König's avatar
      drm/radeon: replace the per ring mutex with a global one · d6999bc7
      Christian König authored
      
      
      A single global mutex for ring submissions seems sufficient.
      Signed-off-by: default avatarChristian König <deathsimple@vodafone.de>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      d6999bc7
    • Jerome Glisse's avatar
      drm/radeon: fix possible lack of synchronization btw ttm and other ring · 133f4cb3
      Jerome Glisse authored
      
      
      We need to sync with the GFX ring as ttm might have schedule bo move
      on it and new command scheduled for other ring need to wait for bo
      data to be in place.
      Signed-off-by: default avatarJerome Glisse <jglisse@redhat.com>
      Reviewed by: Christian König <christian.koenig@amd.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      133f4cb3
  2. 07 May, 2012 15 commits
  3. 06 May, 2012 5 commits
  4. 05 May, 2012 8 commits
  5. 04 May, 2012 8 commits