diff options
Diffstat (limited to '')
| -rw-r--r-- | debian/patches-rt/0061-drm-i915-Do-not-disable-preemption-for-resets.patch | 110 |
1 files changed, 110 insertions, 0 deletions
diff --git a/debian/patches-rt/0061-drm-i915-Do-not-disable-preemption-for-resets.patch b/debian/patches-rt/0061-drm-i915-Do-not-disable-preemption-for-resets.patch new file mode 100644 index 000000000..db8400741 --- /dev/null +++ b/debian/patches-rt/0061-drm-i915-Do-not-disable-preemption-for-resets.patch @@ -0,0 +1,110 @@ +From 1d651fe6c67cb3b355cc228f75289657496520ff Mon Sep 17 00:00:00 2001 +From: Tvrtko Ursulin <tvrtko.ursulin@intel.com> +Date: Fri, 18 Aug 2023 22:45:25 -0400 +Subject: [PATCH 61/62] drm/i915: Do not disable preemption for resets +Origin: https://www.kernel.org/pub/linux/kernel/projects/rt/6.1/older/patches-6.1.69-rt21.tar.xz + +[commit 40cd2835ced288789a685aa4aa7bc04b492dcd45 in linux-rt-devel] + +Commit ade8a0f59844 ("drm/i915: Make all GPU resets atomic") added a +preempt disable section over the hardware reset callback to prepare the +driver for being able to reset from atomic contexts. + +In retrospect I can see that the work item at a time was about removing +the struct mutex from the reset path. Code base also briefly entertained +the idea of doing the reset under stop_machine in order to serialize +userspace mmap and temporary glitch in the fence registers (see +eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on struct_mutex"), +but that never materialized and was soon removed in 2caffbf11762 +("drm/i915: Revoke mmaps and prevent access to fence registers across +reset") and replaced with a SRCU based solution. + +As such, as far as I can see, today we still have a requirement that +resets must not sleep (invoked from submission tasklets), but no need to +support invoking them from a truly atomic context. + +Given that the preemption section is problematic on RT kernels, since the +uncore lock becomes a sleeping lock and so is invalid in such section, +lets try and remove it. Potential downside is that our short waits on GPU +to complete the reset may get extended if CPU scheduling interferes, but +in practice that probably isn't a deal breaker. + +In terms of mechanics, since the preemption disabled block is being +removed we just need to replace a few of the wait_for_atomic macros into +busy looping versions which will work (and not complain) when called from +non-atomic sections. + +Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> +Cc: Chris Wilson <chris.p.wilson@intel.com> +Cc: Paul Gortmaker <paul.gortmaker@windriver.com> +Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> +Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> +Link: https://lore.kernel.org/r/20230705093025.3689748-1-tvrtko.ursulin@linux.intel.com +Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> +[PG: backport from v6.4-rt ; minor context fixup caused by b7d70b8b06ed] +Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> +Signed-off-by: Clark Williams <williams@redhat.com> +--- + drivers/gpu/drm/i915/gt/intel_reset.c | 12 +++++------- + 1 file changed, 5 insertions(+), 7 deletions(-) + +diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c +index 10b930eaa8cb..6108a449cd19 100644 +--- a/drivers/gpu/drm/i915/gt/intel_reset.c ++++ b/drivers/gpu/drm/i915/gt/intel_reset.c +@@ -174,13 +174,13 @@ static int i915_do_reset(struct intel_gt *gt, + /* Assert reset for at least 20 usec, and wait for acknowledgement. */ + pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE); + udelay(50); +- err = wait_for_atomic(i915_in_reset(pdev), 50); ++ err = _wait_for_atomic(i915_in_reset(pdev), 50, 0); + + /* Clear the reset request. */ + pci_write_config_byte(pdev, I915_GDRST, 0); + udelay(50); + if (!err) +- err = wait_for_atomic(!i915_in_reset(pdev), 50); ++ err = _wait_for_atomic(!i915_in_reset(pdev), 50, 0); + + return err; + } +@@ -200,7 +200,7 @@ static int g33_do_reset(struct intel_gt *gt, + struct pci_dev *pdev = to_pci_dev(gt->i915->drm.dev); + + pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE); +- return wait_for_atomic(g4x_reset_complete(pdev), 50); ++ return _wait_for_atomic(g4x_reset_complete(pdev), 50, 0); + } + + static int g4x_do_reset(struct intel_gt *gt, +@@ -217,7 +217,7 @@ static int g4x_do_reset(struct intel_gt *gt, + + pci_write_config_byte(pdev, I915_GDRST, + GRDOM_MEDIA | GRDOM_RESET_ENABLE); +- ret = wait_for_atomic(g4x_reset_complete(pdev), 50); ++ ret = _wait_for_atomic(g4x_reset_complete(pdev), 50, 0); + if (ret) { + GT_TRACE(gt, "Wait for media reset failed\n"); + goto out; +@@ -225,7 +225,7 @@ static int g4x_do_reset(struct intel_gt *gt, + + pci_write_config_byte(pdev, I915_GDRST, + GRDOM_RENDER | GRDOM_RESET_ENABLE); +- ret = wait_for_atomic(g4x_reset_complete(pdev), 50); ++ ret = _wait_for_atomic(g4x_reset_complete(pdev), 50, 0); + if (ret) { + GT_TRACE(gt, "Wait for render reset failed\n"); + goto out; +@@ -718,9 +718,7 @@ int __intel_gt_reset(struct intel_gt *gt, intel_engine_mask_t engine_mask) + intel_uncore_forcewake_get(gt->uncore, FORCEWAKE_ALL); + for (retry = 0; ret == -ETIMEDOUT && retry < retries; retry++) { + GT_TRACE(gt, "engine_mask=%x\n", engine_mask); +- preempt_disable(); + ret = reset(gt, engine_mask, retry); +- preempt_enable(); + } + intel_uncore_forcewake_put(gt->uncore, FORCEWAKE_ALL); + +-- +2.43.0 + |