1. 10 7月, 2013 3 次提交
  2. 08 7月, 2013 1 次提交
  3. 01 7月, 2013 2 次提交
  4. 11 3月, 2013 1 次提交
  5. 20 2月, 2013 1 次提交
  6. 15 2月, 2013 1 次提交
  7. 05 2月, 2013 1 次提交
  8. 20 1月, 2013 1 次提交
    • D
      drm/nouveau: try to protect nbo->pin_refcount · 0ae6d7bc
      Daniel Vetter 提交于
      ... by moving the bo_pin/bo_unpin manipulation of the pin_refcount
      under the protection of the ttm reservation lock. pin/unpin seems
      to get called from all over the place, so atm this is completely racy.
      
      After this patch there are only a few places in cleanup functions
      left which access ->pin_refcount without locking. But I'm hoping that
      those are safe and some other code invariant guarantees that this
      won't blow up.
      
      In any case, I only need to fix up pin/unpin to make ->pageflip work
      safely, so let's keep it at that.
      
      Add a comment to the header to explain the new locking rule.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0ae6d7bc
  9. 04 1月, 2013 1 次提交
  10. 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
  11. 20 11月, 2012 3 次提交
  12. 16 10月, 2012 1 次提交
  13. 03 10月, 2012 9 次提交
  14. 24 5月, 2012 9 次提交
  15. 23 5月, 2012 2 次提交
  16. 22 5月, 2012 1 次提交
  17. 22 3月, 2012 1 次提交
  18. 26 1月, 2012 1 次提交
    • B
      drm/ttm: fix two regressions since move_notify changes · 9f1feed2
      Ben Skeggs 提交于
      Both changes in dc97b340 cause serious
      regressions in the nouveau driver.
      
      move_notify() was originally able to presume that bo->mem is the old node,
      and new_mem is the new node.  The above commit moves the call to
      move_notify() to after move() has been done, which means that now, sometimes,
      new_mem isn't the new node at all, bo->mem is, and new_mem points at a
      stale, possibly-just-been-killed-by-move node.
      
      This is clearly not a good situation.  This patch reverts this change, and
      replaces it with a cleanup in the move() failure path instead.
      
      The second issue is that the call to move_notify() from cleanup_memtype_use()
      causes the TTM ghost objects to get passed into the driver.  This is clearly
      bad as the driver knows nothing about these "fake" TTM BOs, and ends up
      accessing uninitialised memory.
      
      I worked around this in nouveau's move_notify() hook by ensuring the BO
      destructor was nouveau's.  I don't particularly like this solution, and
      would rather TTM never pass the driver these objects.  However, I don't
      clearly understand the reason why we're calling move_notify() here anyway
      and am happy to work around the problem in nouveau instead of breaking the
      behaviour expected by other drivers.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
      Cc: Jerome Glisse <j.glisse@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      9f1feed2