On Wed, 2018-03-28 at 18:53 +0100, Chris Wilson wrote: > As intel_wait_for_register_fw() may use, and if successful only use, a > busy-wait loop, the might_sleep() warning is a little over-zealous. > Restrict it to a might_sleep_if() a slow timeout is specified (and so > the caller authorises use of a usleep). > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > --- > drivers/gpu/drm/i915/intel_uncore.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c > index f37ecfc69e49..44c4654443ba 100644 > --- a/drivers/gpu/drm/i915/intel_uncore.c > +++ b/drivers/gpu/drm/i915/intel_uncore.c > @@ -1996,7 +1996,7 @@ int __intel_wait_for_register(struct drm_i915_private *dev_priv, > u32 reg_value; > int ret; > > - might_sleep(); > + might_sleep_if(slow_timeout_ms); __wait_for() already has a might_sleep(), why is this needed? > > spin_lock_irq(&dev_priv->uncore.lock); > intel_uncore_forcewake_get__locked(dev_priv, fw); > @@ -2008,7 +2008,7 @@ int __intel_wait_for_register(struct drm_i915_private *dev_priv, > intel_uncore_forcewake_put__locked(dev_priv, fw); > spin_unlock_irq(&dev_priv->uncore.lock); > > - if (ret) > + if (ret && slow_timeout_ms) > ret = __wait_for(reg_value = I915_READ_NOTRACE(reg), > (reg_value & mask) == value, > slow_timeout_ms * 1000, 10, 1000); _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
