diff options
| author | Zhi A Wang <zhi.wang.linux2@gmail.com> | 2021-08-26 16:38:34 +0200 |
|---|---|---|
| committer | Rodrigo Vivi <rodrigo.vivi@intel.com> | 2021-11-01 21:38:12 +0100 |
| commit | af6c83ae25a556376ff08291200716232b5a6efc (patch) | |
| tree | e2cdfe7a583237a1ebc41b39d2efba2e2846e8c0 | |
| parent | drm/i915/dmabuf: fix broken build (diff) | |
| download | linux-af6c83ae25a556376ff08291200716232b5a6efc.tar.xz linux-af6c83ae25a556376ff08291200716232b5a6efc.zip | |
drm/i915/gvt: fix the usage of ww lock in gvt scheduler.
As the APIs related to ww lock in i915 was changed recently, the usage of
ww lock in GVT-g scheduler needs to be changed accrodingly. We noticed a
deadlock when GVT-g scheduler submits the workload to i915. After some
investigation, it seems the way of how to use ww lock APIs has been
changed. Releasing a ww now requires a explicit i915_gem_ww_ctx_fini().
Fixes: 67f1120381df ("drm/i915/gvt: Introduce per object locking in GVT scheduler.")
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhi A Wang <zhi.a.wang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210826143834.25410-1-zhi.a.wang@intel.com
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
(cherry picked from commit d168cd797982db9db617113644c87b8f5f3cf27e)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
| -rw-r--r-- | drivers/gpu/drm/i915/gvt/scheduler.c | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c index 0d18e13e3468..6c804102528b 100644 --- a/drivers/gpu/drm/i915/gvt/scheduler.c +++ b/drivers/gpu/drm/i915/gvt/scheduler.c @@ -576,7 +576,7 @@ retry: /* No one is going to touch shadow bb from now on. */ i915_gem_object_flush_map(bb->obj); - i915_gem_object_unlock(bb->obj); + i915_gem_ww_ctx_fini(&ww); } } return 0; @@ -630,7 +630,7 @@ retry: return ret; } - i915_gem_object_unlock(wa_ctx->indirect_ctx.obj); + i915_gem_ww_ctx_fini(&ww); /* FIXME: we are not tracking our pinned VMA leaving it * up to the core to fix up the stray pin_count upon |