1. 14 12月, 2012 3 次提交
  2. 13 12月, 2012 24 次提交
  3. 11 12月, 2012 11 次提交
  4. 10 12月, 2012 2 次提交
    • 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
    • M
      drm/ttm: cope with reserved buffers on lru list in ttm_mem_evict_first, v2 · e7ab2019
      Maarten Lankhorst 提交于
      Replace the goto loop with a simple for each loop, and only run the
      delayed destroy cleanup if we can reserve the buffer first.
      
      No race occurs, since lru lock is never dropped any more. An empty list
      and a list full of unreservable buffers both cause -EBUSY to be returned,
      which is identical to the previous situation, because previously buffers
      on the lru list were always guaranteed to be reservable.
      
      This should work since currently ttm guarantees items on the lru are
      always reservable, and reserving items blockingly with some bo held
      are enough to cause you to run into a deadlock.
      
      Currently this is not a concern since removal off the lru list and
      reservations are always done with atomically, but when this guarantee
      no longer holds, we have to handle this situation or end up with
      possible deadlocks.
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      e7ab2019