Quoting Mika Kuoppala (2017-08-30 12:16:08) > Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > > > All callers do want a synchronous switch to the kernel context, that is > > by the time the call returns, the GPU has evicted all user contexts and > > now has the kernel context pinned. As all callers want this behaviour, > > refactor the common wait-for-idle into the switch. > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> > > --- > > drivers/gpu/drm/i915/i915_gem.c | 6 ------ > > drivers/gpu/drm/i915/i915_gem_context.c | 4 +++- > > drivers/gpu/drm/i915/i915_gem_evict.c | 14 +------------- > > 3 files changed, 4 insertions(+), 20 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > > index 890fe2802973..18ba74be286c 100644 > > --- a/drivers/gpu/drm/i915/i915_gem.c > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > @@ -4564,12 +4564,6 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv) > > if (ret) > > goto err_unlock; > > > > - ret = i915_gem_wait_for_idle(dev_priv, > > - I915_WAIT_INTERRUPTIBLE | > > - I915_WAIT_LOCKED); > > - if (ret) > > - goto err_unlock; > > - > > assert_kernel_context_is_current(dev_priv); > > i915_gem_contexts_lost(dev_priv); > > mutex_unlock(&dev->struct_mutex); > > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c > > index 58a2a44f88bd..f70b05e682ac 100644 > > --- a/drivers/gpu/drm/i915/i915_gem_context.c > > +++ b/drivers/gpu/drm/i915/i915_gem_context.c > > @@ -924,7 +924,9 @@ int i915_gem_switch_to_kernel_context(struct drm_i915_private *dev_priv) > > return ret; > > } > > > > - return 0; > > + return i915_gem_wait_for_idle(dev_priv, > > + I915_WAIT_INTERRUPTIBLE | > > + I915_WAIT_LOCKED); > > This wont apply due to special case EIO handling the previous > suspend hardening patches introduced. Please explain why the EIO > needs to passthrough and not return. Hmm, hopefully my earlier reply turns up... But as I was writing up an assert for add_request, I realise that we know allow set-wedged to be unlocked and so we do not have the strict control over requests-vs-wedging anymore. The idea still remains, if we set-wedged as we build the request, we do want to cancel it and report the -EIO. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx