On 28/06/16 15:30, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
host2guc_action does not appear to be called from atomic context
so a more polite wait_for macro should be used. Especially since
the timeout is 10ms.
Maybe. However we don't really want to sleep if the action takes only a
few microseconds, which some of them do. Maybe we need an optimistic
spin for a few uS to handle the quick commands followed by a sleeping
wait in the cases where it takes long enough that we don't mind the
extra wakeup latency?
.Dave.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Reported-by: Imre Deak <imre.d...@intel.com>
Cc: Dave Gordon <david.s.gor...@intel.com>
Cc: Imre Deak <imre.d...@intel.com>
---
drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 355b6475e74c..fcc7982f8141 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(host2guc_action_response(dev_priv, &status), 10);
if (status != GUC2HOST_STATUS_SUCCESS) {
/*
* Either the GuC explicitly returned an error (which
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
