[Intel-gfx] [PATCH] drm/i915: Do not lie about atomic wait granularity

Chris Wilson chris at chris-wilson.co.uk
Mon Feb 1 13:30:52 UTC 2016


On Mon, Feb 01, 2016 at 01:17:35PM +0000, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> 
> Currently the wait_for_atomic_us only allows for a millisecond
> granularity which is not nice towards callers requesting small
> micro-second waits.
> 
> Re-implement it so micro-second granularity is really supported
> and not just in the name of the macro.
> 
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> ---
> Danger - this might break things which currently work by accident!
> ---
>  drivers/gpu/drm/i915/intel_drv.h | 21 ++++++++++++++++++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index f620023ed134..9e8a1202194c 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -63,10 +63,25 @@
>  	ret__;								\
>  })
>  
> +#define _wait_for_atomic(COND, US) ({ \
> +	unsigned long end__; \
> +	int ret__ = 0; \
> +	get_cpu(); \

Hmm, by virtue of its name (and original intent), we are expected to be
in an atomic context and could just do a BUG_ON(!in_atomic()) to catch
misuse. Since the removal of the panic modeset, all callers outside of
intel_uncore.c are definitely abusing this and we would be better to use
a usleep[_range]() variant instead.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list