Re: [RFC] drm/i915: hybrid wait-for macro

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 28/06/16 17:56, Dave Gordon wrote:
Part spin-wait, part sleep-wait.
Plus one example of where it might be used.

Signed-off-by: Dave Gordon <david.s.gordon@xxxxxxxxx>
---
  drivers/gpu/drm/i915/i915_guc_submission.c |  2 +-
  drivers/gpu/drm/i915/intel_drv.h           | 10 ++++++++++
  2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c
index 355b647..ff99910 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -98,7 +98,7 @@ static int host2guc_action(struct intel_guc *guc, u32 *data, u32 len)
  	I915_WRITE(HOST2GUC_INTERRUPT, HOST2GUC_TRIGGER);

  	/* No HOST2GUC command should take longer than 10ms */
-	ret = wait_for_atomic(host2guc_action_response(dev_priv, &status), 10);
+	ret = wait_for_hybrid(host2guc_action_response(dev_priv, &status), 10, 10);
  	if (status != GUC2HOST_STATUS_SUCCESS) {
  		/*
  		 * Either the GuC explicitly returned an error (which
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3156d8d..096e07c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -103,6 +103,16 @@
  #define wait_for_atomic(COND, MS)	_wait_for_atomic((COND), (MS) * 1000)
  #define wait_for_atomic_us(COND, US)	_wait_for_atomic((COND), (US))

+/* Hybrid wait:
+ * 	first spin-wait for up to <US> microseconds,
+ * 	if <COND> still not true, sleep-wait for MS milliseconds
+ */
+#define	wait_for_hybrid(COND, US, MS)	({				\
+		int ret__ = wait_for_atomic_us(COND, US);		\
+		if (ret__) ret__ = wait_for(COND, MS);			\
+		ret__;							\
+	})
+
  #define KHz(x) (1000 * (x))
  #define MHz(x) KHz(1000 * (x))

Wouldn't harm anything if you know typical GuC response time is under 10us and 10ms timeout is backed with some documentation.

Another idea could be a wait_for variant which takes those values, so typical and maximum response time, and then it could decide statically in the macro what to do.

Regards,

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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux