[Intel-gfx] [PATCH] drm/i915: Tidy up GEM_TRACE around execlists

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-12-20 13:21:45)
> 
> On 20/12/2017 12:43, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2017-12-20 12:39:42)
> >>
> >> On 20/12/2017 09:06, Chris Wilson wrote:
> >>> Looking at the coordination of resets with the submission of execlists,
> >>> it will be useful to have a GEM_TRACE for when we issue the reset.
> >>> Whilst there tidy up the other GEM_TRACE to always include the engine
> >>> name, and be careful not to trust any pointers prior to asserts.
> >>>
> >>> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >>> Cc: Mika Kuoppala <mika.kuoppala at linux.intel.com>
> >>> Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> >>> Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> >>> ---
> >>>    drivers/gpu/drm/i915/intel_lrc.c | 6 ++++--
> >>>    1 file changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> >>> index 6205d320b86f..84029806cf3f 100644
> >>> --- a/drivers/gpu/drm/i915/intel_lrc.c
> >>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> >>> @@ -504,7 +504,7 @@ static void inject_preempt_context(struct intel_engine_cs *engine)
> >>>        ce->ring->tail &= (ce->ring->size - 1);
> >>>        ce->lrc_reg_state[CTX_RING_TAIL+1] = ce->ring->tail;
> >>>    
> >>> -     GEM_TRACE("\n");
> >>> +     GEM_TRACE("%s\n", engine->name);
> >>>        for (n = execlists_num_ports(&engine->execlists); --n; )
> >>>                elsp_write(0, engine->execlists.elsp);
> >>>    
> >>> @@ -906,7 +906,7 @@ static void execlists_submission_tasklet(unsigned long data)
> >>>                        GEM_TRACE("%s out[0]: ctx=%d.%d, seqno=%x\n",
> >>>                                  engine->name,
> >>>                                  port->context_id, count,
> >>> -                               rq->global_seqno);
> >>> +                               rq ? rq->global_seqno : 0);
> >>
> >> rq can be NULL here? What's with the --count below then, wouldn't it
> >> underflow since I assume rq == NULL means count == 0 as well?
> > 
> > Exactly. If rq is NULL then count must be 0. However, we want to show the
> > output from before the BUG_ON so that we have it available in case the
> > BUG does explode.
> 
> Okay makes sense.
> 
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>

Thanks, pushed to see what explodes next. If we are right, rq is NULL
here, which should be impossible. Exciting times.
-Chris