]> git.baikalelectronics.ru Git - kernel.git/commit
drm/i915/gt: Wait for CSB entries on Tigerlake
authorChris Wilson <chris@chris-wilson.co.uk>
Tue, 15 Sep 2020 13:49:21 +0000 (14:49 +0100)
committerChris Wilson <chris@chris-wilson.co.uk>
Tue, 15 Sep 2020 14:33:53 +0000 (15:33 +0100)
commit4dc940b05ea7ec0ab0530ff3805d415fb3f70b82
treeb33e1f69f42e174e9b4dd410de2f5b78e8f12d5f
parent07a9ce5358624395a843852925be4acdf4cdc7d8
drm/i915/gt: Wait for CSB entries on Tigerlake

On Tigerlake, we are seeing a repeat of commit ce0d7d94f822 ("drm/i915/icl:
Forcibly evict stale csb entries") where, presumably, due to a missing
Global Observation Point synchronisation, the write pointer of the CSB
ringbuffer is updated _prior_ to the contents of the ringbuffer. That is
we see the GPU report more context-switch entries for us to parse, but
those entries have not been written, leading us to process stale events,
and eventually report a hung GPU.

However, this effect appears to be much more severe than we previously
saw on Icelake (though it might be best if we try the same approach
there as well and measure), and Bruce suggested the good idea of resetting
the CSB entry after use so that we can detect when it has been updated by
the GPU. By instrumenting how long that may be, we can set a reliable
upper bound for how long we should wait for:

    513 late, avg of 61 retries (590 ns), max of 1061 retries (10099 ns)

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2045
References: ce0d7d94f822 ("drm/i915/icl: Forcibly evict stale csb entries")
References: HSDES#22011327657, HSDES#1508287568
Suggested-by: Bruce Chang <yu.bruce.chang@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Bruce Chang <yu.bruce.chang@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: stable@vger.kernel.org # v5.4
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200915134923.30088-2-chris@chris-wilson.co.uk
drivers/gpu/drm/i915/gt/intel_lrc.c