[Intel-gfx] [PATCH] drm/i915: Restore context and pd for ringbuffer submission after reset

Chris Wilson chris at chris-wilson.co.uk
Mon Feb 6 15:51:33 UTC 2017


On Mon, Feb 06, 2017 at 05:33:34PM +0200, Mika Kuoppala wrote:
> Chris Wilson <chris at chris-wilson.co.uk> writes:
> >  static void reset_ring_common(struct intel_engine_cs *engine,
> >  			      struct drm_i915_gem_request *request)
> >  {
> > -	struct intel_ring *ring = request->ring;
> > +	if (request) {
> > +		struct drm_i915_private *dev_priv = request->i915;
> > +		struct intel_context *ce = &request->ctx->engine[engine->id];
> > +		struct i915_hw_ppgtt *ppgtt;
> > +
> > +		if (ce->state) {
> > +			I915_WRITE(CCID,
> > +				   i915_ggtt_offset(ce->state) |
> > +				   BIT(3) | BIT(2) | CCID_EN);
> 
> Can we assume here that the hw reset have made the ringbuffer
> empty (as hw head == tail == 0)?

Yes. This is after reset. Perhaps not so much as assume they are 0, but
the engine is completely idle, which is all we need.

> BIT8 should be set.

Not according to the gen6/7 bspec I checked.

> Bits 3|2 shuold be EXTENDED_STATE_SAVE|RESTORE_ENABLE.

That would require touching i915_reg.h. I don't want to start a bad
habit.
 
> Does the BIT2 affect the way the context will be loaded?

Yes. It may be the next context and valid. If is the hung ctx, do we
care? Certainly we should assume it can recover. From very quick thought
experiments, it seems more prudent to try to reload the context.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list