[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