[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