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

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

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@intel.com>
> ---
>   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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx