[Intel-gfx] [PATCH] drm/i915/guc: Do not use wait_for_atomic in host2guc_action
Dave Gordon
david.s.gordon at intel.com
Tue Jun 28 15:50:43 UTC 2016
On 28/06/16 15:30, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin at 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.ursulin at intel.com>
> Reported-by: Imre Deak <imre.deak at intel.com>
> Cc: Dave Gordon <david.s.gordon at intel.com>
> Cc: Imre Deak <imre.deak at 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
>
More information about the Intel-gfx
mailing list