On 09/08/17 16:38, Chris Wilson wrote:
This is called from execlist context init which we need to be unlocked.
Commit f89823c21224 ("drm/i915/perf: Implement
I915_PERF_ADD/REMOVE_CONFIG interface") added a lockdep assert to this
path for unclear reasons, remove it again!
Fixes: 701f8231a2fe ("drm/i915/perf: prune OA configs")
Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Cc: Lionel Landwerlin <lionel.g.landwerlin@xxxxxxxxx>
Cc: Matthew Auld <matthew.auld@xxxxxxxxx>
---
drivers/gpu/drm/i915/i915_perf.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 1be355d14e8a..3bdf53faae24 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2173,8 +2173,6 @@ void i915_oa_init_reg_state(struct intel_engine_cs *engine,
struct drm_i915_private *dev_priv = engine->i915;
struct i915_perf_stream *stream = dev_priv->perf.oa.exclusive_stream;
I was trying to avoid adding a new lock for exclusive_stream.
If we can't rely on dev_priv->drm.struct_mutex to update
exclusive_stream, I believe we need to add a new lock.
Or maybe some other mechanism?
- lockdep_assert_held(&dev_priv->drm.struct_mutex);
-
if (engine->id != RCS)
return;
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
