intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
* [Intel-gfx] [PATCH v2] drm/i915/guc: Stop using mutex while sending CTB messages
@ 2020-02-01 13:52 Michal Wajdeczko
  2020-02-01 14:06 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/guc: Stop using mutex while sending CTB messages (rev2) Patchwork
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Michal Wajdeczko @ 2020-02-01 13:52 UTC (permalink / raw)
  To: intel-gfx

While we are always using CT "send" buffer to send request messages
to GuC, we usually don't ask GuC to use CT "receive" buffer to send
back response messages, since almost all returned data can fit into
reserved bits in status dword inside CT descriptor. However, relying
on data modifications inside CT descriptor requires use of mutex to
allow only single CT request in flight, until we read back that status
dword from the CT descriptor.

But some H2G actions (like AUTHENTICATE_HUC, and more to come) are
like one-way requests for which we don't care about immediate status,
since we will use a different way to confirm that given action was
completed (ie. HUC_STATUS reg is used to verify HuC authentication).

If we ask GuC to always send response messages over "receive" buffer
for all requests for which we care about their status, then we can
use CT descriptor option only for our new one-way requests, for which
status can be temporary ignored.

Since we only need to protect CT descriptor during reading/writing
from the command buffer, we can drop mutex and switch to spinlock.

v2: use separate locks, and set subclass (Chris)

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
---
 drivers/gpu/drm/i915/gt/uc/intel_guc.c    |   2 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 146 ++++++++--------------
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |   4 +
 3 files changed, 60 insertions(+), 92 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index c4c1523da7a6..d5938c1d44a2 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -519,7 +519,7 @@ int intel_guc_sample_forcewake(struct intel_guc *guc)
 int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset)
 {
 	u32 action[] = {
-		INTEL_GUC_ACTION_AUTHENTICATE_HUC,
+		INTEL_GUC_ACTION_AUTHENTICATE_HUC | GUC_SEND_FLAG_NO_RESPONSE,
 		rsa_offset
 	};
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 11742fca0e9e..bf9a40da1f7f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -41,10 +41,16 @@ static void ct_incoming_request_worker_func(struct work_struct *w);
  */
 void intel_guc_ct_init_early(struct intel_guc_ct *ct)
 {
+	int i;
+
 	spin_lock_init(&ct->requests.lock);
 	INIT_LIST_HEAD(&ct->requests.pending);
 	INIT_LIST_HEAD(&ct->requests.incoming);
 	INIT_WORK(&ct->requests.worker, ct_incoming_request_worker_func);
+	for (i = 0; i < ARRAY_SIZE(ct->ctbs); i++) {
+		spin_lock_init(&ct->ctbs[i].lock);
+		lockdep_set_subclass(&ct->ctbs[i].lock, i);
+	}
 }
 
 static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)
@@ -88,13 +94,6 @@ static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc,
 	desc->owner = CTB_OWNER_HOST;
 }
 
-static void guc_ct_buffer_desc_reset(struct guc_ct_buffer_desc *desc)
-{
-	desc->head = 0;
-	desc->tail = 0;
-	desc->is_in_error = 0;
-}
-
 static int guc_action_register_ct_buffer(struct intel_guc *guc,
 					 u32 desc_addr,
 					 u32 type)
@@ -317,6 +316,7 @@ static int ct_write(struct intel_guc_ct *ct,
 {
 	struct intel_guc_ct_buffer *ctb = &ct->ctbs[CTB_SEND];
 	struct guc_ct_buffer_desc *desc = ctb->desc;
+	u32 action_code = action[0] & GUC_CT_MSG_ACTION_MASK;
 	u32 head = desc->head;
 	u32 tail = desc->tail;
 	u32 size = desc->size;
@@ -325,6 +325,8 @@ static int ct_write(struct intel_guc_ct *ct,
 	u32 *cmds = ctb->cmds;
 	unsigned int i;
 
+	lockdep_assert_held(&ctb->lock);
+
 	if (unlikely(desc->is_in_error))
 		return -EPIPE;
 
@@ -359,7 +361,7 @@ static int ct_write(struct intel_guc_ct *ct,
 	header = (len << GUC_CT_MSG_LEN_SHIFT) |
 		 (GUC_CT_MSG_WRITE_FENCE_TO_DESC) |
 		 (want_response ? GUC_CT_MSG_SEND_STATUS : 0) |
-		 (action[0] << GUC_CT_MSG_ACTION_SHIFT);
+		 (action_code << GUC_CT_MSG_ACTION_SHIFT);
 
 	CT_DEBUG(ct, "writing %*ph %*ph %*ph\n",
 		 4, &header, 4, &fence, 4 * (len - 1), &action[1]);
@@ -387,62 +389,11 @@ static int ct_write(struct intel_guc_ct *ct,
 	return -EPIPE;
 }
 
-/**
- * wait_for_ctb_desc_update - Wait for the CT buffer descriptor update.
- * @desc:	buffer descriptor
- * @fence:	response fence
- * @status:	placeholder for status
- *
- * Guc will update CT buffer descriptor with new fence and status
- * after processing the command identified by the fence. Wait for
- * specified fence and then read from the descriptor status of the
- * command.
- *
- * Return:
- * *	0 response received (status is valid)
- * *	-ETIMEDOUT no response within hardcoded timeout
- * *	-EPROTO no response, CT buffer is in error
- */
-static int wait_for_ctb_desc_update(struct guc_ct_buffer_desc *desc,
-				    u32 fence,
-				    u32 *status)
-{
-	int err;
-
-	/*
-	 * Fast commands should complete in less than 10us, so sample quickly
-	 * up to that length of time, then switch to a slower sleep-wait loop.
-	 * No GuC command should ever take longer than 10ms.
-	 */
-#define done (READ_ONCE(desc->fence) == fence)
-	err = wait_for_us(done, 10);
-	if (err)
-		err = wait_for(done, 10);
-#undef done
-
-	if (unlikely(err)) {
-		DRM_ERROR("CT: fence %u failed; reported fence=%u\n",
-			  fence, desc->fence);
-
-		if (WARN_ON(desc->is_in_error)) {
-			/* Something went wrong with the messaging, try to reset
-			 * the buffer and hope for the best
-			 */
-			guc_ct_buffer_desc_reset(desc);
-			err = -EPROTO;
-		}
-	}
-
-	*status = desc->status;
-	return err;
-}
-
 /**
  * wait_for_ct_request_update - Wait for CT request state update.
  * @req:	pointer to pending request
- * @status:	placeholder for status
  *
- * For each sent request, Guc shall send bac CT response message.
+ * For each sent request, Guc shall send back CT response message.
  * Our message handler will update status of tracked request once
  * response message with given fence is received. Wait here and
  * check for valid response status value.
@@ -451,7 +402,7 @@ static int wait_for_ctb_desc_update(struct guc_ct_buffer_desc *desc,
  * *	0 response received (status is valid)
  * *	-ETIMEDOUT no response within hardcoded timeout
  */
-static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
+static int wait_for_ct_request_update(struct ct_request *req)
 {
 	int err;
 
@@ -466,10 +417,6 @@ static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
 		err = wait_for(done, 10);
 #undef done
 
-	if (unlikely(err))
-		DRM_ERROR("CT: fence %u err %d\n", req->fence, err);
-
-	*status = req->status;
 	return err;
 }
 
@@ -477,14 +424,11 @@ static int ct_send(struct intel_guc_ct *ct,
 		   const u32 *action,
 		   u32 len,
 		   u32 *response_buf,
-		   u32 response_buf_size,
-		   u32 *status)
+		   u32 response_buf_size)
 {
 	struct intel_guc_ct_buffer *ctb = &ct->ctbs[CTB_SEND];
-	struct guc_ct_buffer_desc *desc = ctb->desc;
 	struct ct_request request;
 	unsigned long flags;
-	u32 fence;
 	int err;
 
 	GEM_BUG_ON(!ct->enabled);
@@ -492,8 +436,8 @@ static int ct_send(struct intel_guc_ct *ct,
 	GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
 	GEM_BUG_ON(!response_buf && response_buf_size);
 
-	fence = ct_get_next_fence(ct);
-	request.fence = fence;
+	spin_lock(&ctb->lock);
+	request.fence = ct_get_next_fence(ct);
 	request.status = 0;
 	request.response_len = response_buf_size;
 	request.response_buf = response_buf;
@@ -502,21 +446,22 @@ static int ct_send(struct intel_guc_ct *ct,
 	list_add_tail(&request.link, &ct->requests.pending);
 	spin_unlock_irqrestore(&ct->requests.lock, flags);
 
-	err = ct_write(ct, action, len, fence, !!response_buf);
+	err = ct_write(ct, action, len, request.fence, true);
+	spin_unlock(&ctb->lock);
+
 	if (unlikely(err))
 		goto unlink;
 
 	intel_guc_notify(ct_to_guc(ct));
 
-	if (response_buf)
-		err = wait_for_ct_request_update(&request, status);
-	else
-		err = wait_for_ctb_desc_update(desc, fence, status);
+	err = wait_for_ct_request_update(&request);
 	if (unlikely(err))
 		goto unlink;
 
-	if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status)) {
-		err = -EIO;
+	if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(request.status)) {
+		CT_ERROR(ct, "Error response: action=%#x fence=%u status=%#x\n",
+			 action[0], request.fence, request.status);
+		err = -ENXIO;
 		goto unlink;
 	}
 
@@ -529,7 +474,7 @@ static int ct_send(struct intel_guc_ct *ct,
 		/* There shall be no response payload */
 		WARN_ON(request.response_len);
 		/* Return data decoded from the status dword */
-		err = INTEL_GUC_MSG_TO_DATA(*status);
+		err = INTEL_GUC_MSG_TO_DATA(request.status);
 	}
 
 unlink:
@@ -540,14 +485,32 @@ static int ct_send(struct intel_guc_ct *ct,
 	return err;
 }
 
+static int ct_send_no_response(struct intel_guc_ct *ct,
+			       const u32 *action, u32 len)
+{
+	struct intel_guc_ct_buffer *ctb = &ct->ctbs[CTB_SEND];
+	int err;
+
+	GEM_BUG_ON(!ct->enabled);
+	GEM_BUG_ON(!len);
+	GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
+
+	spin_lock(&ctb->lock);
+	err = ct_write(ct, action, len, ct_get_next_fence(ct), false);
+	spin_unlock(&ctb->lock);
+
+	if (likely(!err))
+		intel_guc_notify(ct_to_guc(ct));
+
+	return err;
+}
+
 /*
  * Command Transport (CT) buffer based GuC send function.
  */
 int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 *action, u32 len,
 		      u32 *response_buf, u32 response_buf_size)
 {
-	struct intel_guc *guc = ct_to_guc(ct);
-	u32 status = ~0; /* undefined */
 	int ret;
 
 	if (unlikely(!ct->enabled)) {
@@ -555,18 +518,15 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 *action, u32 len,
 		return -ENODEV;
 	}
 
-	mutex_lock(&guc->send_mutex);
+	if (*action & GUC_SEND_FLAG_NO_RESPONSE)
+		ret = ct_send_no_response(ct, action, len);
+	else
+		ret = ct_send(ct, action, len, response_buf, response_buf_size);
 
-	ret = ct_send(ct, action, len, response_buf, response_buf_size, &status);
-	if (unlikely(ret < 0)) {
-		CT_ERROR(ct, "Sending action %#x failed (err=%d status=%#X)\n",
-			 action[0], ret, status);
-	} else if (unlikely(ret)) {
-		CT_DEBUG(ct, "send action %#x returned %d (%#x)\n",
-			 action[0], ret, ret);
-	}
+	if (unlikely(ret < 0))
+		CT_ERROR(ct, "Failed send: action=%#x (err=%d)\n",
+			 *action, ret);
 
-	mutex_unlock(&guc->send_mutex);
 	return ret;
 }
 
@@ -597,6 +557,8 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
 	unsigned int len;
 	unsigned int i;
 
+	lockdep_assert_held(&ctb->lock);
+
 	if (unlikely(desc->is_in_error))
 		return -EPIPE;
 
@@ -849,7 +811,9 @@ void intel_guc_ct_event_handler(struct intel_guc_ct *ct)
 	}
 
 	do {
+		spin_lock(&ct->ctbs[CTB_RECV].lock);
 		err = ct_read(ct, msg);
+		spin_unlock(&ct->ctbs[CTB_RECV].lock);
 		if (err)
 			break;
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index 97913bbb8be3..616b8209b731 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
@@ -28,10 +28,12 @@ struct intel_guc;
  * holds the commands.
  *
  * @desc: pointer to the buffer descriptor
+ * @lock: protects access to the descriptor
  * @cmds: pointer to the commands buffer
  */
 struct intel_guc_ct_buffer {
 	struct guc_ct_buffer_desc *desc;
+	spinlock_t lock;
 	u32 *cmds;
 };
 
@@ -70,6 +72,8 @@ static inline bool intel_guc_ct_enabled(struct intel_guc_ct *ct)
 	return ct->enabled;
 }
 
+#define GUC_SEND_FLAG_NO_RESPONSE	0x80000000
+
 int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 *action, u32 len,
 		      u32 *response_buf, u32 response_buf_size);
 void intel_guc_ct_event_handler(struct intel_guc_ct *ct);
-- 
2.19.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/guc: Stop using mutex while sending CTB messages (rev2)
  2020-02-01 13:52 [Intel-gfx] [PATCH v2] drm/i915/guc: Stop using mutex while sending CTB messages Michal Wajdeczko
@ 2020-02-01 14:06 ` Patchwork
  2020-02-01 14:25 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
  2020-02-01 19:16 ` [Intel-gfx] [PATCH v2] drm/i915/guc: Stop using mutex while sending CTB messages Chris Wilson
  2 siblings, 0 replies; 4+ messages in thread
From: Patchwork @ 2020-02-01 14:06 UTC (permalink / raw)
  To: Michal Wajdeczko; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/guc: Stop using mutex while sending CTB messages (rev2)
URL   : https://patchwork.freedesktop.org/series/72827/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b71663451270 drm/i915/guc: Stop using mutex while sending CTB messages
-:352: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#352: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h:36:
+	spinlock_t lock;

total: 0 errors, 0 warnings, 1 checks, 299 lines checked

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Stop using mutex while sending CTB messages (rev2)
  2020-02-01 13:52 [Intel-gfx] [PATCH v2] drm/i915/guc: Stop using mutex while sending CTB messages Michal Wajdeczko
  2020-02-01 14:06 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/guc: Stop using mutex while sending CTB messages (rev2) Patchwork
@ 2020-02-01 14:25 ` Patchwork
  2020-02-01 19:16 ` [Intel-gfx] [PATCH v2] drm/i915/guc: Stop using mutex while sending CTB messages Chris Wilson
  2 siblings, 0 replies; 4+ messages in thread
From: Patchwork @ 2020-02-01 14:25 UTC (permalink / raw)
  To: Michal Wajdeczko; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/guc: Stop using mutex while sending CTB messages (rev2)
URL   : https://patchwork.freedesktop.org/series/72827/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7854 -> Patchwork_16376
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_16376 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_16376, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16376/index.html

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_16376:

### IGT changes ###

#### Possible regressions ####

  * igt@runner@aborted:
    - fi-cfl-guc:         NOTRUN -> [FAIL][1]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16376/fi-cfl-guc/igt@runner@aborted.html

  
Known issues
------------

  Here are the changes found in Patchwork_16376 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@i915_module_load@reload:
    - fi-icl-u2:          [PASS][2] -> [DMESG-WARN][3] ([i915#289])
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7854/fi-icl-u2/igt@i915_module_load@reload.html
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16376/fi-icl-u2/igt@i915_module_load@reload.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-7500u:       [PASS][4] -> [FAIL][5] ([fdo#111096] / [i915#323])
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7854/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16376/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html

  * igt@vgem_basic@dmabuf-fence:
    - fi-icl-dsi:         [PASS][6] -> [DMESG-WARN][7] ([i915#109])
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7854/fi-icl-dsi/igt@vgem_basic@dmabuf-fence.html
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16376/fi-icl-dsi/igt@vgem_basic@dmabuf-fence.html

  
#### Possible fixes ####

  * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
    - fi-icl-u2:          [DMESG-WARN][8] ([i915#263]) -> [PASS][9]
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7854/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16376/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html

  
#### Warnings ####

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-icl-u2:          [FAIL][10] ([i915#323]) -> [DMESG-WARN][11] ([IGT#4] / [i915#263])
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7854/fi-icl-u2/igt@kms_chamelium@common-hpd-after-suspend.html
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16376/fi-icl-u2/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@runner@aborted:
    - fi-glk-dsi:         [FAIL][12] ([k.org#202321]) -> [FAIL][13] ([k.org#202321] / [k.org#204565])
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7854/fi-glk-dsi/igt@runner@aborted.html
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16376/fi-glk-dsi/igt@runner@aborted.html

  
  [IGT#4]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/4
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [i915#109]: https://gitlab.freedesktop.org/drm/intel/issues/109
  [i915#263]: https://gitlab.freedesktop.org/drm/intel/issues/263
  [i915#289]: https://gitlab.freedesktop.org/drm/intel/issues/289
  [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
  [k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321
  [k.org#204565]: https://bugzilla.kernel.org/show_bug.cgi?id=204565


Participating hosts (48 -> 46)
------------------------------

  Additional (5): fi-hsw-peppy fi-gdg-551 fi-ivb-3770 fi-skl-lmem fi-kbl-7560u 
  Missing    (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-n2820 fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7854 -> Patchwork_16376

  CI-20190529: 20190529
  CI_DRM_7854: 727605cdef77d1e7eafb7e4c05b0ee74132a0930 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5410: 9d3872ede14307ef4adb0866f8474f5c41e6b1c1 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16376: b716634512706ee0f820df7c55f6b36404428cbe @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

b71663451270 drm/i915/guc: Stop using mutex while sending CTB messages

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16376/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Stop using mutex while sending CTB messages
  2020-02-01 13:52 [Intel-gfx] [PATCH v2] drm/i915/guc: Stop using mutex while sending CTB messages Michal Wajdeczko
  2020-02-01 14:06 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/guc: Stop using mutex while sending CTB messages (rev2) Patchwork
  2020-02-01 14:25 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
@ 2020-02-01 19:16 ` Chris Wilson
  2 siblings, 0 replies; 4+ messages in thread
From: Chris Wilson @ 2020-02-01 19:16 UTC (permalink / raw)
  To: Michal Wajdeczko, intel-gfx

Quoting Michal Wajdeczko (2020-02-01 13:52:31)
>  void intel_guc_ct_init_early(struct intel_guc_ct *ct)
>  {
> +       int i;
> +
>         spin_lock_init(&ct->requests.lock);
>         INIT_LIST_HEAD(&ct->requests.pending);
>         INIT_LIST_HEAD(&ct->requests.incoming);
>         INIT_WORK(&ct->requests.worker, ct_incoming_request_worker_func);
> +       for (i = 0; i < ARRAY_SIZE(ct->ctbs); i++) {
> +               spin_lock_init(&ct->ctbs[i].lock);
> +               lockdep_set_subclass(&ct->ctbs[i].lock, i);

Ugh this then hits the lockdep bug where the lock has to be used or else
it miscounts.

<4>[  276.588423] DEBUG_LOCKS_WARN_ON(debug_atomic_read(nr_unused_locks) != nr_unused)
<4>[  276.588431] WARNING: CPU: 9 PID: 1107 at kernel/locking/lockdep_proc.c:249 lockdep_stats_show+0x9b8/0xa40
<4>[  276.588452] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal coretemp snd_intel_dspcfg snd_hda_codec mei_hdcp snd_hwdep crct10dif_pclmul snd_hda_core crc32_pclmul snd_pcm ghash_clmulni_intel e1000e mei_me ptp mei pps_core prime_numbers [last unloaded: i915]
<4>[  276.588492] CPU: 9 PID: 1107 Comm: igt_runner Tainted: G     U            5.5.0-CI-Patchwork_16376+ #1
<4>[  276.588504] Hardware name: Micro-Star International Co., Ltd. MS-7B54/Z370M MORTAR (MS-7B54), BIOS 1.10 12/28/2017
<4>[  276.588519] RIP: 0010:lockdep_stats_show+0x9b8/0xa40
<4>[  276.588527] Code: 00 85 c0 0f 84 6e f8 ff ff 8b 05 03 bd 62 01 85 c0 0f 85 60 f8 ff ff 48 c7 c6 28 fd 2c 82 48 c7 c7 82 c7 2b 82 e8 38 30 f9 ff <0f> 0b e9 46 f8 ff ff 48 c7 44 24 50 00 00 00 00 45 31 e4 48 c7 44
<4>[  276.588549] RSP: 0018:ffffc90000e37dc0 EFLAGS: 00010282
<4>[  276.588557] RAX: 0000000000000000 RBX: 0000000000000474 RCX: 0000000000000001
<4>[  276.588567] RDX: 0000000080000001 RSI: 0000000000000000 RDI: ffffffff8112e5bc
<4>[  276.588576] RBP: 0000000000000043 R08: 0000000000000000 R09: 000000000003ae40
<4>[  276.588586] R10: ffffc90000e37dc0 R11: 0000000000000453 R12: 0000000000013384
<4>[  276.588595] R13: 0000000000000014 R14: ffff88823c4fc238 R15: 0000000000000003
<4>[  276.588605] FS:  00007fd2e01b8980(0000) GS:ffff888266c80000(0000) knlGS:0000000000000000
<4>[  276.588616] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[  276.588624] CR2: 00007ffd8febc150 CR3: 0000000252cd4006 CR4: 00000000003606e0
<4>[  276.588633] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>[  276.588642] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
<4>[  276.588652] Call Trace:
<4>[  276.588663]  seq_read+0xdb/0x3f0
<4>[  276.588671]  ? do_sys_open+0x13b/0x250
<4>[  276.588680]  proc_reg_read+0x34/0x60
<4>[  276.588687]  vfs_read+0x96/0x160
<4>[  276.588695]  ksys_read+0x9f/0xe0
<4>[  276.588703]  do_syscall_64+0x4f/0x220
<4>[  276.588711]  entry_SYSCALL_64_after_hwframe+0x49/0xbe

        /*
         * Due to an interesting quirk in lockdep's internal debug tracking,
         * after setting a subclass we must ensure the lock is used. Otherwise,
         * nr_unused_locks is incremented once too often.
         */
#ifdef CONFIG_DEBUG_LOCK_ALLOC
        lock_map_acquire(&ct->ctbs[i].lock.dep_map);
        lock_map_release(&ct->ctbs[i].lock.dep_map);
#endif


> +       }
>  }
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-02-01 19:16 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-01 13:52 [Intel-gfx] [PATCH v2] drm/i915/guc: Stop using mutex while sending CTB messages Michal Wajdeczko
2020-02-01 14:06 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/guc: Stop using mutex while sending CTB messages (rev2) Patchwork
2020-02-01 14:25 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2020-02-01 19:16 ` [Intel-gfx] [PATCH v2] drm/i915/guc: Stop using mutex while sending CTB messages Chris Wilson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).