On Mon, Feb 06, 2017 at 05:33:34PM +0200, Mika Kuoppala wrote:
> Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
