[Intel-gfx] [PATCH 2/2] drm/i915: Let hardware keep track of ctx buf read pointer

[Chris Wilson]

On Mon, Jun 08, 2015 at 01:15:39PM +0300, Ville Syrjälä wrote:
> On Mon, Jun 08, 2015 at 12:12:41PM +0300, Mika Kuoppala wrote:
> > Chris Wilson <chris at chris-wilson.co.uk> writes:
> > 
> > > On Fri, May 22, 2015 at 08:17:22PM +0300, Mika Kuoppala wrote:
> > >> We initialize the internal read pointer to zero on init/reset,
> > >> but only the reset will actually zero the write pointer.
> > >> This means that on module reload we might re-read context
> > >> status buffers that were written prior reload.
> > >> 
> > >> It is safest just to let the hardware keep track of the read pointer,
> > >> so that we get valid value as there is no driver state involved.
> > >> 
> > >> Signed-off-by: Mika Kuoppala <mika.kuoppala at intel.com>
> > >> ---
> > >>  drivers/gpu/drm/i915/i915_debugfs.c     |  6 +++---
> > >>  drivers/gpu/drm/i915/intel_lrc.c        | 11 ++++-------
> > >>  drivers/gpu/drm/i915/intel_ringbuffer.h |  2 +-
> > >>  3 files changed, 8 insertions(+), 11 deletions(-)
> > >> 
> > >> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> > >> index fece922..b079dd3 100644
> > >> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > >> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > >> @@ -2026,8 +2026,8 @@ static int i915_execlists(struct seq_file *m, void *data)
> > >>  	struct drm_i915_private *dev_priv = dev->dev_private;
> > >>  	struct intel_engine_cs *ring;
> > >>  	u32 status_pointer;
> > >> -	u8 read_pointer;
> > >> -	u8 write_pointer;
> > >> +	u32 read_pointer;
> > >> +	u32 write_pointer;
> > >
> > > I don't follow this change. It seems like this is to avoid having to
> > > explicitly widen the type when converting the 32bit register value later
> > > on?
> > >
> > 
> > Yes that is the sole purpose. I don't see any drawback.
> 
> C likes to promote most things to int anyway, so I'm not sure what this
> widening is all about.

Hmm, I anticapted a warning about doing a shift wider than the available
type, but it does do the int promotion implicitly.

The warning you get if you try hard enough is

tmp.c:7:5: warning: conversion to ‘uint8_t {aka unsigned char}’ from
‘int’ may alter its value [-Wconversion]
  u8 <<= 8;

So here it definitely should be cleanest code wins.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre