[Intel-xe] [PATCH v7 4/7] drm/xe/ct: tweak lock ordering for freq_lock

[Matthew Auld]

Lockdep spits out:

Possible unsafe locking scenario:
   CPU0				CPU1
   ----				----
   lock(&xe->mem_access.lock);
				lock(&pc->freq_lock);
				lock(&xe->mem_access.lock);
   lock(&pc->freq_lock);

It looks like we already mostly take care to ensure that the mem_access
ref is taken outside of taking freq_lock, since that is also grabbed
from the runtime_pm callbacks, except for one spot in guc_ct_send_recv()
which was grabbing the mem_access ref, even though the caller is already
holding freq_lock. It looks like all the callers are already holding the
mem_access.ref, so just switch over to use guc_ct_send_locked().

Signed-off-by: Matthew Auld <matthew.auld at intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi at intel.com>
---
 drivers/gpu/drm/xe/xe_guc_ct.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
index 9dc906f2651a..7a8c9d6a03f3 100644
--- a/drivers/gpu/drm/xe/xe_guc_ct.c
+++ b/drivers/gpu/drm/xe/xe_guc_ct.c
@@ -689,7 +689,9 @@ static int guc_ct_send_recv(struct xe_guc_ct *ct, const u32 *action, u32 len,
 retry:
 	g2h_fence_init(&g2h_fence, response_buffer);
 retry_same_fence:
-	ret = guc_ct_send(ct, action, len, 0, 0, &g2h_fence);
+	mutex_lock(&ct->lock);
+	ret = guc_ct_send_locked(ct, action, len, 0, 0, &g2h_fence);
+	mutex_unlock(&ct->lock);
 	if (unlikely(ret == -ENOMEM)) {
 		void *ptr;
 
-- 
2.40.1