--- /dev/null
+From 5c6c13cd1102caf92d006a3cf4591c0229019daf Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Tue, 11 Aug 2020 10:25:32 +0100
+Subject: drm/i915: Drop runtime-pm assert from vgpu io accessors
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit 5c6c13cd1102caf92d006a3cf4591c0229019daf upstream.
+
+The "mmio" writes into vgpu registers are simple memory traps from the
+guest into the host. We do not need to assert in the guest that the
+device is awake for the io as we do not write to the device itself.
+
+However, over time we have refactored all the mmio accessors with the
+result that the vgpu reuses the gen2 accessors and so inherits the
+assert for runtime-pm of the native device. The assert though has
+actually been there since commit 3be0bf5acca6 ("drm/i915: Create vGPU
+specific MMIO operations to reduce traps").
+
+References: 3be0bf5acca6 ("drm/i915: Create vGPU specific MMIO operations to reduce traps")
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Yan Zhao <yan.y.zhao@intel.com>
+Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
+Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
+Cc: stable@vger.kernel.org
+Link: https://patchwork.freedesktop.org/patch/msgid/20200811092532.13753-1-chris@chris-wilson.co.uk
+(cherry picked from commit 0e65ce24a33c1d37da4bf43c34e080334ec6cb60)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_uncore.c | 27 ++++++++++++++++++++++++++-
+ 1 file changed, 26 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/intel_uncore.c
++++ b/drivers/gpu/drm/i915/intel_uncore.c
+@@ -1124,6 +1124,18 @@ unclaimed_reg_debug(struct intel_uncore
+ spin_unlock(&uncore->debug->lock);
+ }
+
++#define __vgpu_read(x) \
++static u##x \
++vgpu_read##x(struct intel_uncore *uncore, i915_reg_t reg, bool trace) { \
++ u##x val = __raw_uncore_read##x(uncore, reg); \
++ trace_i915_reg_rw(false, reg, val, sizeof(val), trace); \
++ return val; \
++}
++__vgpu_read(8)
++__vgpu_read(16)
++__vgpu_read(32)
++__vgpu_read(64)
++
+ #define GEN2_READ_HEADER(x) \
+ u##x val = 0; \
+ assert_rpm_wakelock_held(uncore->rpm);
+@@ -1327,6 +1339,16 @@ __gen_reg_write_funcs(gen8);
+ #undef GEN6_WRITE_FOOTER
+ #undef GEN6_WRITE_HEADER
+
++#define __vgpu_write(x) \
++static void \
++vgpu_write##x(struct intel_uncore *uncore, i915_reg_t reg, u##x val, bool trace) { \
++ trace_i915_reg_rw(true, reg, val, sizeof(val), trace); \
++ __raw_uncore_write##x(uncore, reg, val); \
++}
++__vgpu_write(8)
++__vgpu_write(16)
++__vgpu_write(32)
++
+ #define ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, x) \
+ do { \
+ (uncore)->funcs.mmio_writeb = x##_write8; \
+@@ -1647,7 +1669,10 @@ static void uncore_raw_init(struct intel
+ {
+ GEM_BUG_ON(intel_uncore_has_forcewake(uncore));
+
+- if (IS_GEN(uncore->i915, 5)) {
++ if (intel_vgpu_active(uncore->i915)) {
++ ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, vgpu);
++ ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, vgpu);
++ } else if (IS_GEN(uncore->i915, 5)) {
+ ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, gen5);
+ ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, gen5);
+ } else {
--- /dev/null
+From 9b99e5ba3e5d68039bd6b657e4bbe520a3521f4c Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Thu, 15 Oct 2020 20:50:23 +0100
+Subject: drm/i915/gt: Delay execlist processing for tgl
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit 9b99e5ba3e5d68039bd6b657e4bbe520a3521f4c upstream.
+
+When running gem_exec_nop, it floods the system with many requests (with
+the goal of userspace submitting faster than the HW can process a single
+empty batch). This causes the driver to continually resubmit new
+requests onto the end of an active context, a flood of lite-restore
+preemptions. If we time this just right, Tigerlake hangs.
+
+Inserting a small delay between the processing of CS events and
+submitting the next context, prevents the hang. Naturally it does not
+occur with debugging enabled. The suspicion then is that this is related
+to the issues with the CS event buffer, and inserting an mmio read of
+the CS pointer status appears to be very successful in preventing the
+hang. Other registers, or uncached reads, or plain mb, do not prevent
+the hang, suggesting that register is key -- but that the hang can be
+prevented by a simple udelay, suggests it is just a timing issue like
+that encountered by commit 233c1ae3c83f ("drm/i915/gt: Wait for CSB
+entries on Tigerlake"). Also note that the hang is not prevented by
+applying CTX_DESC_FORCE_RESTORE, or by inserting a delay on the GPU
+between requests.
+
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
+Cc: Bruce Chang <yu.bruce.chang@intel.com>
+Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
+Cc: stable@vger.kernel.org
+Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20201015195023.32346-1-chris@chris-wilson.co.uk
+(cherry picked from commit 6ca7217dffaf1abba91558e67a2efb655ac91405)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
++++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
+@@ -1574,6 +1574,9 @@ static void process_csb(struct intel_eng
+ if (!inject_preempt_hang(execlists))
+ ring_set_paused(engine, 0);
+
++ /* XXX Magic delay for tgl */
++ ENGINE_POSTING_READ(engine, RING_CONTEXT_STATUS_PTR);
++
+ WRITE_ONCE(execlists->pending[0], NULL);
+ break;
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
