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

Chris Wilson chris at chris-wilson.co.uk
Sat May 23 09:10:54 PDT 2015


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?

Otherwise I agree very much with the sentiment of the patch!
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list