On Mon, Jun 06, 2016 at 03:55:18PM +0100, Tvrtko Ursulin wrote:
>
> On 03/06/16 17:08, Chris Wilson wrote:
> >diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> >index 2a736f4a0fe5..4013ad92cdc6 100644
> >--- a/drivers/gpu/drm/i915/i915_irq.c
> >+++ b/drivers/gpu/drm/i915/i915_irq.c
> >@@ -2951,7 +2951,7 @@ static int semaphore_passed(struct intel_engine_cs *engine)
> > if (signaller->hangcheck.deadlock >= I915_NUM_ENGINES)
> > return -1;
> >
> >- if (i915_seqno_passed(signaller->get_seqno(signaller), seqno))
> >+ if (i915_seqno_passed(intel_engine_get_seqno(engine), seqno))
>
> Should be signaller, not engine, by the look of it.
Ta!
> >@@ -1543,7 +1537,9 @@ static int
> > pc_render_add_request(struct drm_i915_gem_request *req)
> > {
> > struct intel_engine_cs *engine = req->engine;
> >- u32 scratch_addr = engine->scratch.gtt_offset + 2 * CACHELINE_BYTES;
> >+ u32 addr = engine->status_page.gfx_addr +
> >+ (I915_GEM_HWS_INDEX << MI_STORE_DWORD_INDEX_SHIFT);
> >+ u32 scratch_addr = addr;
> > int ret;
>
> Before my time. :)
>
> Why was this code flushing all that space but above where it was
> writting the seqno?
The idea is simply that we need to delay the command streamer by
performing N writes before asserting the interrupt. The choice of where
is purely paranoia to make sure the GPU can't pack multiple writes into
one transaction.
> With this change it is flushing the seqno area as well.
s/flushing/writing/
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
