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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx>
>> ---
>>  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.
-Mika

> Otherwise I agree very much with the sentiment of the patch!
> -Chris
>
> -- 
> Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux