Re: [PATCH 07/11] drm/i915/tdr: Add support for per engine reset recovery

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 26, 2016 at 05:40:53PM +0100, Arun Siluvery wrote:
> This change implements support for per-engine reset as an initial, less
> intrusive hang recovery option to be attempted before falling back to the
> legacy full GPU reset recovery mode if necessary. This is only supported
> from Gen8 onwards.
> 
> Hangchecker determines which engines are hung and invokes error handler to
> recover from it. Error handler schedules recovery for each of those engines
> that are hung. The recovery procedure is as follows,
>  - force engine to idle: this is done by issuing a reset request
>  - identifies the request that caused the hang and it is dropped
>  - reset and re-init engine
>  - restart submissions to the engine
> 
> If engine reset fails then we fall back to heavy weight full gpu reset
> which resets all engines and reinitiazes complete state of HW and SW.
> 
> Possible reasons for failure,
>  - engine not ready for reset
>  - if the HW and SW doesn't agree on the context that caused the hang
>  - reset itself failed for some reason
> 
> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx>
> Signed-off-by: Tomas Elf <tomas.elf@xxxxxxxxx>
> Signed-off-by: Arun Siluvery <arun.siluvery@xxxxxxxxxxxxxxx>
> ---
>  drivers/gpu/drm/i915/i915_drv.c     | 55 +++++++++++++++++++++++++++++++++----
>  drivers/gpu/drm/i915/i915_drv.h     |  3 ++
>  drivers/gpu/drm/i915/i915_gem.c     |  2 +-
>  drivers/gpu/drm/i915/intel_lrc.h    |  4 +++
>  drivers/gpu/drm/i915/intel_uncore.c | 33 ++++++++++++++++++++++
>  5 files changed, 90 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 5c20e5d..8151aa9 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1824,17 +1824,60 @@ error:
>   * Returns zero on successful reset or otherwise an error code.
>   *
>   * Procedure is fairly simple:
> - *  - force engine to idle
> - *  - save current state which includes head and current request
> - *  - reset engine
> - *  - restore saved state and resubmit context
> + *    - force engine to idle: this is done by issuing a reset request
> + *    - identifies the request that caused the hang and it is retired
> + *    - reset engine
> + *    - restart submissions to the engine
>   */
>  int i915_reset_engine(struct intel_engine_cs *engine)
>  {
> +	struct drm_i915_private *dev_priv = engine->i915;
>  	int ret;
>  
> -	/* FIXME: replace me with engine reset sequence */
> -	ret = -ENODEV;
> +	/* Ensure irq handler finishes or is cancelled. */
> +	tasklet_kill(&engine->irq_tasklet);
> +
> +	i915_gem_reset_engine_status(engine);

Not yet safe to be used lockless.

> +	/*Take wake lock to prevent power saving mode */

Why else would you be taking it? We know the wakelock prevents the GT
power well disappearing, the question is why is that important now
across the entirety of this sequence? That's what you explain in
comments.

> +	intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
> +
> +	ret = intel_request_for_reset(engine);
> +	if (ret) {
> +		DRM_ERROR("Failed to disable %s\n", engine->name);
> +		goto out;
> +	}
> +
> +	ret = intel_execlists_reset_prepare(engine);
> +	if (ret)
> +		goto enable_engine;
> +
> +	ret = intel_gpu_reset(dev_priv, intel_engine_flag(engine));
> +	if (ret) {
> +		DRM_ERROR("Failed to reset %s, ret=%d\n", engine->name, ret);
> +		goto enable_engine;
> +	}
> +
> +	ret = engine->init_hw(engine);
> +	if (ret)
> +		goto out;
> +
> +	/* Restart submissions to the engine after reset */
> +	intel_execlists_restart_submission(engine);

Clumsy. See above as we already have an entry point that can initiate
the hw.

> +enable_engine:
> +	/*
> +	 * we only need to enable engine if we cannot prepare engine for
> +	 * reset or reset fails. If the reset is successful, engine gets
> +	 * enabled automatically so we can skip this step.
> +	 */
> +	if (ret)

Then why is the normal path coming through here?

> +		intel_clear_reset_request(engine);
> +
> +out:
> +	/* Wake up anything waiting on this engine's queue */
> +	intel_engine_wakeup(engine);

? Random call with incorrect locking. What do you think you are
achieving here because it's not what the comment implies.

> +	intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
>  
>  	return ret;
>  }
> +/*
> + * On gen8+ a reset request has to be issued via the reset control register
> + * before a GPU engine can be reset in order to stop the command streamer
> + * and idle the engine. This replaces the legacy way of stopping an engine
> + * by writing to the stop ring bit in the MI_MODE register.
> + */
> +int intel_request_for_reset(struct intel_engine_cs *engine)

intel_engine_reset_begin()

It would be preferrable if we can avoid using request here as we are
talking about reseting the hung request elsewhere in this chain.

> +{
> +	if (!intel_has_engine_reset(engine->i915)) {
> +		DRM_ERROR("Engine Reset not supported on Gen%d\n",
> +			  INTEL_INFO(engine->i915)->gen);

ERROR?

> +		return -EINVAL;
return -ENODEV;

> +	}
> +
> +	return gen8_request_engine_reset(engine);
> +}

gen8_engine_reset_begin()

> +/*
> + * It is possible to back off from a previously issued reset request by simply
> + * clearing the reset request bit in the reset control register.
> + */
> +int intel_clear_reset_request(struct intel_engine_cs *engine)

intel_engine_reset_cancel()

> +{
> +{
> +	if (!intel_has_engine_reset(engine->i915)) {
> +		DRM_ERROR("Request to clear reset not supported on Gen%d\n",
> +			  INTEL_INFO(engine->i915)->gen);
> +		return -EINVAL;
> +	}
> +
> +	gen8_unrequest_engine_reset(engine);

gen8_engine_reset_cancel()

(only suggestions for avoiding having confusion over requests)


-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux