Am 25.11.22 um 12:14 schrieb Tvrtko Ursulin:
+ Matt
On 25/11/2022 10:21, Christian König wrote:
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König <christian.koenig@xxxxxxx>
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 5247d88b3c13..d409a77449a3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -599,13 +599,16 @@ i915_ttm_resource_get_st(struct
drm_i915_gem_object *obj,
static int i915_ttm_truncate(struct drm_i915_gem_object *obj)
{
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
- int err;
+ long err;
WARN_ON_ONCE(obj->mm.madv == I915_MADV_WILLNEED);
- err = ttm_bo_wait(bo, true, false);
- if (err)
+ err = dma_resv_wait_timeout(bo->base.resv, DMA_RESV_USAGE_BOOKKEEP,
+ true, 15 * HZ);
This 15 second stuck out a bit for me and then on a slightly deeper
look it seems this timeout will "leak" into a few of i915 code paths.
If we look at the difference between the legacy shmem and ttm backend
I am not sure if the legacy one is blocking or not - but if it can
block I don't think it would have an arbitrary timeout like this. Matt
your thoughts?
That's exactly the reason why I try to remove the ttm_bo_wait() as mid
layer here. It hides the fact that we don't wait forever for BOs to
become idle.
This is functional identical to the old code. If you want some other
behavior feel free to note what's desired and I will implement it.
Regards,
Christian.
Regards,
Tvrtko
+ if (err < 0)
return err;
+ if (err == 0)
+ return -EBUSY;
err = i915_ttm_move_notify(bo);
if (err)
