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

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Wed Jun 29 09:29:25 UTC 2016


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 at 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


More information about the Intel-gfx mailing list