On Mon, Feb 01, 2016 at 01:17:35PM +0000, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin <[email protected]> > > 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 <[email protected]> > --- > 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 _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
