From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 6/9] drm/i915/execlists: Reset CSB write pointer after reset
Date: Thu, 28 Jun 2018 12:37:09 +0100 [thread overview]
Message-ID: <cb160120-6b1d-ec07-b7ed-2f9284b4452c@linux.intel.com> (raw)
In-Reply-To: <153018544447.8693.8743018949303663087@mail.alporthouse.com>
On 28/06/2018 12:30, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-06-28 12:02:30)
>>
>> On 28/06/2018 11:17, Chris Wilson wrote:
>>> Quoting Tvrtko Ursulin (2018-06-28 11:06:25)
>>>>
>>>> On 27/06/2018 22:07, Chris Wilson wrote:
>>>>> On HW reset, the HW clears the write pointer (to 0). But since it also
>>>>> writes its first CSB entry to slot 0, we need to reset the write pointer
>>>>> back to the element before (so the first entry we read is 0).
>>>>>
>>>>> This is required for the next patch, where we trust the CSB completely!
>>>>>
>>>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>> ---
>>>>> drivers/gpu/drm/i915/intel_lrc.c | 19 +++++++++++++++++--
>>>>> 1 file changed, 17 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
>>>>> index 368a8c74d11d..8b111a268697 100644
>>>>> --- a/drivers/gpu/drm/i915/intel_lrc.c
>>>>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
>>>>> @@ -884,6 +884,21 @@ static void reset_irq(struct intel_engine_cs *engine)
>>>>> clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
>>>>> }
>>>>>
>>>>> +static void reset_csb_pointers(struct intel_engine_execlists *execlists)
>>>>> +{
>>>>> + /*
>>>>> + * After a reset, the HW starts writing into CSB entry [0]. We
>>>>> + * therefore have to set our HEAD pointer back one entry so that
>>>>> + * the *first* entry we check is entry 0. To complicate this further,
>>>>> + * as we don't wait for the first interrupt after reset, we have to
>>>>> + * fake the HW write to point back to the last entry so that our
>>>>> + * inline comparison of our cached head position against the last HW
>>>>> + * write works even before the first interrupt.
>>>>> + */
>>>>> + execlists->csb_head = GEN8_CSB_ENTRIES - 1;
>>>>> + WRITE_ONCE(*execlists->csb_write, (GEN8_CSB_ENTRIES - 1) | 0xff << 16);
>>>>
>>>> Use _MASKED_FIELD and GEN8_CSB_WRITE_PTR_MASK?
>>>
>>> Hah, there goes my attempt to kill off unused magic.
>>
>> At least _MASKED_FIELD makes it clearer.
>>
>> But the u8 trick is still evil since here you even explicitly do a fake
>> masked write on hwsp. Ugly and evil. How about storing
>> execlists->csb_write_default at init time and applying it here?
>
> Honestly, I thought it made sense next to the READ_ONCE(*csb_write).
>
> Could I just convince you with another comment pleading guilty to the
> atrocities?
I'd prefer we did not write random stuff into hwsp. Like if one day
someone is debugging something, they could see either 0xff00?? or 0x??
in there depending on the timings. Then would have to waste time
figuring out what's happening.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-06-28 11:37 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-27 21:07 [PATCH 1/9] drm/i915: Drop posting reads to flush master interrupts Chris Wilson
2018-06-27 21:07 ` [PATCH 2/9] drm/i915/execlists: Pull submit after dequeue under timeline lock Chris Wilson
2018-06-27 21:07 ` [PATCH 3/9] drm/i915/execlists: Pull CSB reset under the timeline.lock Chris Wilson
2018-06-27 21:07 ` [PATCH 4/9] drm/i915/execlists: Process one CSB update at a time Chris Wilson
2018-06-27 21:07 ` [PATCH 5/9] drm/i915/execlists: Unify CSB access pointers Chris Wilson
2018-06-28 10:02 ` Tvrtko Ursulin
2018-06-28 10:10 ` Chris Wilson
2018-06-28 10:58 ` Tvrtko Ursulin
2018-06-28 11:05 ` Chris Wilson
2018-06-28 11:13 ` [PATCH v2] " Chris Wilson
2018-06-28 11:21 ` Tvrtko Ursulin
2018-06-27 21:07 ` [PATCH 6/9] drm/i915/execlists: Reset CSB write pointer after reset Chris Wilson
2018-06-28 10:06 ` Tvrtko Ursulin
2018-06-28 10:17 ` Chris Wilson
2018-06-28 11:02 ` Tvrtko Ursulin
2018-06-28 11:30 ` Chris Wilson
2018-06-28 11:37 ` Tvrtko Ursulin [this message]
2018-06-28 10:22 ` [PATCH v2] " Chris Wilson
2018-06-28 11:59 ` [PATCH v3] " Chris Wilson
2018-06-28 12:15 ` Tvrtko Ursulin
2018-06-28 12:19 ` Chris Wilson
2018-06-27 21:07 ` [PATCH 7/9] drm/i915/execlists: Stop storing the CSB read pointer in the mmio register Chris Wilson
2018-06-28 10:07 ` Tvrtko Ursulin
2018-06-27 21:07 ` [PATCH 8/9] drm/i915/execlists: Trust the CSB Chris Wilson
2018-06-28 11:29 ` Tvrtko Ursulin
2018-06-28 12:03 ` Chris Wilson
2018-06-27 21:07 ` [PATCH 9/9] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd) Chris Wilson
2018-06-27 21:56 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts Patchwork
2018-06-27 22:13 ` ✓ Fi.CI.BAT: success " Patchwork
2018-06-28 3:46 ` ✓ Fi.CI.IGT: " Patchwork
2018-06-28 10:41 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev2) Patchwork
2018-06-28 11:00 ` ✓ Fi.CI.BAT: success " Patchwork
2018-06-28 11:20 ` ✗ Fi.CI.BAT: failure for series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev3) Patchwork
2018-06-28 12:09 ` ✗ Fi.CI.BAT: failure for series starting with [1/9] drm/i915: Drop posting reads to flush master interrupts (rev4) Patchwork
-- strict thread matches above, loose matches on Subject: below --
2018-06-28 12:33 [PATCH 1/9] drm/i915: Drop posting reads to flush master interrupts Chris Wilson
2018-06-28 12:33 ` [PATCH 6/9] drm/i915/execlists: Reset CSB write pointer after reset Chris Wilson
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=cb160120-6b1d-ec07-b7ed-2f9284b4452c@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--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;
as well as URLs for NNTP newsgroup(s).