public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Imre Deak <imre.deak@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915/bxt: work around HW coherency	issue when accessing GPU seqno
Date: Wed, 01 Jul 2015 16:53:49 +0300	[thread overview]
Message-ID: <87y4j0nfv6.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <871tgsov22.fsf@gaia.fi.intel.com>

Mika Kuoppala <mika.kuoppala@linux.intel.com> writes:

> Imre Deak <imre.deak@intel.com> writes:
>
>> By running igt/store_dword_loop_render on BXT we can hit a coherency
>> problem where the seqno written at GPU command completion time is not
>> seen by the CPU. This results in __i915_wait_request seeing the stale
>> seqno and not completing the request (not considering the lost
>> interrupt/GPU reset mechanism). I also verified that this isn't a case
>> of a lost interrupt, or that the command didn't complete somehow: when
>> the coherency issue occured I read the seqno via an uncached GTT mapping
>> too. While the cached version of the seqno still showed the stale value
>> the one read via the uncached mapping was the correct one.
>>
>> Work around this issue by clflushing the corresponding CPU cacheline
>> following any store of the seqno and preceding any reading of it. When
>> reading it do this only when the caller expects a coherent view.
>>
>> Testcase: igt/store_dword_loop_render
>> Signed-off-by: Imre Deak <imre.deak@intel.com>
>> ---
>>  drivers/gpu/drm/i915/intel_lrc.c        | 17 +++++++++++++++++
>>  drivers/gpu/drm/i915/intel_ringbuffer.h |  7 +++++++
>>  2 files changed, 24 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
>> index 9f5485d..88bc5525 100644
>> --- a/drivers/gpu/drm/i915/intel_lrc.c
>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
>> @@ -1288,12 +1288,29 @@ static int gen8_emit_flush_render(struct intel_ringbuffer *ringbuf,
>>  
>>  static u32 gen8_get_seqno(struct intel_engine_cs *ring, bool lazy_coherency)
>>  {
>> +	/*
>> +	 * On BXT-A1 there is a coherency issue whereby the MI_STORE_DATA_IMM
>> +	 * storing the completed request's seqno occasionally doesn't
>> +	 * invalidate the CPU cache. Work around this by clflushing the
>> +	 * corresponding cacheline whenever the caller wants the coherency to
>> +	 * be guaranteed. Note that this cacheline is known to be
>> +	 * clean at this point, since we only write it in gen8_set_seqno(),
>> +	 * where we also do a clflush after the write. So this clflush in
>> +	 * practice becomes an invalidate operation.
>> +	 */
>> +	if (IS_BROXTON(ring->dev) & !lazy_coherency)
>
> s/&/&& ?

s//Read The Whole Thread Before Replying

-Mika

> -Mika
>
>> +		intel_flush_status_page(ring, I915_GEM_HWS_INDEX);
>> +
>>  	return intel_read_status_page(ring, I915_GEM_HWS_INDEX);
>>  }
>>  
>>  static void gen8_set_seqno(struct intel_engine_cs *ring, u32 seqno)
>>  {
>>  	intel_write_status_page(ring, I915_GEM_HWS_INDEX, seqno);
>> +
>> +	/* See gen8_get_seqno() explaining the reason for the clflush. */
>> +	if (IS_BROXTON(ring->dev))
>> +		intel_flush_status_page(ring, I915_GEM_HWS_INDEX);
>>  }
>>  
>>  static int gen8_emit_request(struct intel_ringbuffer *ringbuf,
>> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h
>> index 39f6dfc..224a25b 100644
>> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
>> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
>> @@ -352,6 +352,13 @@ intel_ring_sync_index(struct intel_engine_cs *ring,
>>  	return idx;
>>  }
>>  
>> +static inline void
>> +intel_flush_status_page(struct intel_engine_cs *ring, int reg)
>> +{
>> +	drm_clflush_virt_range(&ring->status_page.page_addr[reg],
>> +			       sizeof(uint32_t));
>> +}
>> +
>>  static inline u32
>>  intel_read_status_page(struct intel_engine_cs *ring,
>>  		       int reg)
>> -- 
>> 2.1.4
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-07-01 13:54 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-08 16:28 [PATCH 0/2] drm/i915/bxt: work around HW coherency issue Imre Deak
2015-06-08 16:28 ` [PATCH 1/2] drm/i915/bxt: work around HW coherency issue when accessing GPU seqno Imre Deak
2015-06-08 17:08   ` Dave Gordon
2015-06-08 17:12     ` Chris Wilson
2015-06-08 17:34       ` Ville Syrjälä
2015-06-08 18:00         ` Chris Wilson
2015-06-08 18:40           ` Ville Syrjälä
2015-06-08 19:33             ` Dave Gordon
2015-06-10 10:59               ` Imre Deak
2015-06-10 15:10                 ` Jesse Barnes
2015-06-10 15:26                   ` Imre Deak
2015-06-10 15:33                     ` Jesse Barnes
2015-06-10 15:55                       ` Imre Deak
2015-06-10 15:52                     ` Chris Wilson
2015-06-11  8:02                       ` Dave Gordon
2015-06-11  8:20                         ` Chris Wilson
2015-06-11 19:14                         ` Imre Deak
2015-06-08 17:14     ` Imre Deak
2015-06-09  8:21   ` Jani Nikula
2015-06-10 14:07     ` Imre Deak
2015-06-10 14:21       ` Chris Wilson
2015-06-10 14:55         ` Imre Deak
2015-06-10 15:00           ` Ville Syrjälä
2015-06-10 15:16             ` Imre Deak
2015-06-10 15:35               ` Chris Wilson
2015-07-01 13:40   ` Mika Kuoppala
2015-07-01 13:53     ` Mika Kuoppala [this message]
2015-06-08 16:28 ` [PATCH 2/2] drm/i915/bxt: work around HW coherency issue for cached GEM mappings Imre Deak
2015-06-13 18:04   ` shuang.he

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y4j0nfv6.fsf@gaia.fi.intel.com \
    --to=mika.kuoppala@linux.intel.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox