1. 08 8月, 2016 3 次提交
  2. 30 7月, 2016 1 次提交
  3. 08 7月, 2016 7 次提交
  4. 05 5月, 2016 1 次提交
  5. 24 7月, 2015 1 次提交
  6. 23 9月, 2014 1 次提交
  7. 02 9月, 2014 1 次提交
  8. 01 9月, 2014 1 次提交
  9. 08 7月, 2014 1 次提交
  10. 08 1月, 2014 1 次提交
  11. 23 12月, 2013 1 次提交
  12. 18 12月, 2013 1 次提交
  13. 20 11月, 2013 1 次提交
  14. 06 11月, 2013 2 次提交
  15. 25 7月, 2013 1 次提交
    • D
      drm/ttm: convert to unified vma offset manager · 72525b3f
      David Herrmann 提交于
      Use the new vma-manager infrastructure. This doesn't change any
      implementation details as the vma-offset-manager is nearly copied 1-to-1
      from TTM.
      
      The vm_lock is moved into the offset manager so we can drop it from TTM.
      During lookup, we use the vma locking helpers to take a reference to the
      found object.
      In all other scenarios, locking stays the same as before. We always
      guarantee that drm_vma_offset_remove() is called only during destruction.
      Hence, helpers like drm_vma_node_offset_addr() are always safe as long as
      the node has a valid offset.
      
      This also drops the addr_space_offset member as it is a copy of vm_start
      in vma_node objects. Use the accessor functions instead.
      
      v4:
       - remove vm_lock
       - use drm_vma_offset_lock_lookup() to protect lookup (instead of vm_lock)
      
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
      Cc: Martin Peres <martin.peres@labri.fr>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Thomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@gmail.com>
      72525b3f
  16. 28 6月, 2013 1 次提交
  17. 12 4月, 2013 1 次提交
  18. 08 2月, 2013 1 次提交
    • D
      drm/ttm: fix fence locking in ttm_buffer_object_transfer, 2nd try · ff7c60c5
      Daniel Vetter 提交于
      This fixes up
      
      commit e8e89622
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Tue Dec 18 22:25:11 2012 +0100
      
          drm/ttm: fix fence locking in ttm_buffer_object_transfer
      
      which leaves behind a might_sleep in atomic context, since the
      fence_lock spinlock is held over a kmalloc(GFP_KERNEL) call. The fix
      is to revert the above commit and only take the lock where we need it,
      around the call to ->sync_obj_ref.
      
      v2: Fixup things noticed by Maarten Lankhorst:
      - Brown paper bag locking bug.
      - No need for kzalloc if we clear the entire thing on the next line.
      - check for bo->sync_obj (totally unlikely race, but still someone
        else could have snuck in) and clear fbo->sync_obj if it's cleared
        already.
      Reported-by: NDave Airlie <airlied@gmail.com>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      ff7c60c5
  19. 21 1月, 2013 1 次提交
    • D
      ttm: don't destroy old mm_node on memcpy failure · 63054186
      Dave Airlie 提交于
      When we are using memcpy to move objects around, and we fail to memcpy
      due to lack of memory to populate or failure to finish the copy, we don't
      want to destroy the mm_node that has been copied into old_copy.
      
      While working on a new kms driver that uses memcpy, if I overallocated bo's
      up to the memory limits, and eviction failed, then machine would oops soon
      after due to having an active bo with an already freed drm_mm embedded in it,
      freeing it a second time didn't end well.
      Reviewed-by: NJerome Glisse <jglisse@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      63054186
  20. 08 1月, 2013 1 次提交
  21. 10 12月, 2012 1 次提交
    • M
      drm/ttm: remove no_wait_reserve, v3 · 97a875cb
      Maarten Lankhorst 提交于
      All items on the lru list are always reservable, so this is a stupid
      thing to keep. Not only that, it is used in a way which would
      guarantee deadlocks if it were ever to be set to block on reserve.
      
      This is a lot of churn, but mostly because of the removal of the
      argument which can be nested arbitrarily deeply in many places.
      
      No change of code in this patch except removal of the no_wait_reserve
      argument, the previous patch removed the use of no_wait_reserve.
      
      v2:
       - Warn if -EBUSY is returned on reservation, all objects on the list
         should be reservable. Adjusted patch slightly due to conflicts.
      v3:
       - Focus on no_wait_reserve removal only.
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      97a875cb
  22. 20 11月, 2012 2 次提交
  23. 03 10月, 2012 1 次提交
  24. 24 8月, 2012 1 次提交
  25. 06 12月, 2011 2 次提交
  26. 28 10月, 2011 1 次提交
  27. 18 10月, 2011 1 次提交
  28. 01 9月, 2011 1 次提交
    • M
      drm/ttm: add a way to bo_wait for either the last read or last write · dfadbbdb
      Marek Olšák 提交于
      Sometimes we want to know whether a buffer is busy and wait for it (bo_wait).
      However, sometimes it would be more useful to be able to query whether
      a buffer is busy and being either read or written, and wait until it's stopped
      being either read or written. The point of this is to be able to avoid
      unnecessary waiting, e.g. if a GPU has written something to a buffer and is now
      reading that buffer, and a CPU wants to map that buffer for read, it needs to
      only wait for the last write. If there were no write, there wouldn't be any
      waiting needed.
      
      This, or course, requires user space drivers to send read/write flags
      with each relocation (like we have read/write domains in radeon, so we can
      actually use those for something useful now).
      
      Now how this patch works:
      
      The read/write flags should passed to ttm_validate_buffer. TTM maintains
      separate sync objects of the last read and write for each buffer, in addition
      to the sync object of the last use of a buffer. ttm_bo_wait then operates
      with one the sync objects.
      Signed-off-by: NMarek Olšák <maraeo@gmail.com>
      Reviewed-by: NJerome Glisse <jglisse@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      dfadbbdb
  29. 23 8月, 2011 1 次提交