* [Intel-gfx] [PATCH] drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
@ 2022-05-02 22:18 Umesh Nerlige Ramappa
2022-05-02 23:19 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for " Patchwork
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Umesh Nerlige Ramappa @ 2022-05-02 22:18 UTC (permalink / raw)
To: intel-gfx, daniele.ceraolospurio
Current implementation of Wa_22011802037 is limited to the GuC backend
and gen12. Add support for execlist backend and gen11 as well.
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
---
drivers/gpu/drm/i915/gt/intel_engine.h | 2 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 81 ++++++++++++++++++-
.../drm/i915/gt/intel_execlists_submission.c | 7 ++
.../gpu/drm/i915/gt/intel_ring_submission.c | 7 ++
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 81 ++-----------------
6 files changed, 103 insertions(+), 79 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h b/drivers/gpu/drm/i915/gt/intel_engine.h
index 1431f1e9dbee..04e435bce79b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -201,6 +201,8 @@ int intel_ring_submission_setup(struct intel_engine_cs *engine);
int intel_engine_stop_cs(struct intel_engine_cs *engine);
void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
+void intel_engine_wait_for_pending_mi_fw(struct intel_engine_cs *engine);
+
void intel_engine_set_hwsp_writemask(struct intel_engine_cs *engine, u32 mask);
u64 intel_engine_get_active_head(const struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 14c6ddbbfde8..0bda665a407c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1282,10 +1282,10 @@ static int __intel_engine_stop_cs(struct intel_engine_cs *engine,
intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
/*
- * Wa_22011802037 : gen12, Prior to doing a reset, ensure CS is
+ * Wa_22011802037 : gen11, gen12, Prior to doing a reset, ensure CS is
* stopped, set ring stop bit and prefetch disable bit to halt CS
*/
- if (GRAPHICS_VER(engine->i915) == 12)
+ if (GRAPHICS_VER(engine->i915) == 11 || GRAPHICS_VER(engine->i915) == 12)
intel_uncore_write_fw(uncore, RING_MODE_GEN7(engine->mmio_base),
_MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));
@@ -1308,6 +1308,14 @@ int intel_engine_stop_cs(struct intel_engine_cs *engine)
return -ENODEV;
ENGINE_TRACE(engine, "\n");
+ /*
+ * TODO: Occasionally trying to stop the cs times out, but does not
+ * adversely affect functionality. The timeout is set as a config
+ * parameter that defaults to 100ms. Assuming that this timeout is
+ * sufficient for any pending MI_FORCEWAKEs to complete. Once root
+ * caused, the caller must check and handler the return from this
+ * function.
+ */
if (__intel_engine_stop_cs(engine, 1000, stop_timeout(engine))) {
ENGINE_TRACE(engine,
"timed out on STOP_RING -> IDLE; HEAD:%04x, TAIL:%04x\n",
@@ -1334,6 +1342,75 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine)
ENGINE_WRITE_FW(engine, RING_MI_MODE, _MASKED_BIT_DISABLE(STOP_RING));
}
+static u32 __cs_pending_mi_force_wakes(struct intel_engine_cs *engine)
+{
+ static const i915_reg_t _reg[I915_NUM_ENGINES] = {
+ [RCS0] = MSG_IDLE_CS,
+ [BCS0] = MSG_IDLE_BCS,
+ [VCS0] = MSG_IDLE_VCS0,
+ [VCS1] = MSG_IDLE_VCS1,
+ [VCS2] = MSG_IDLE_VCS2,
+ [VCS3] = MSG_IDLE_VCS3,
+ [VCS4] = MSG_IDLE_VCS4,
+ [VCS5] = MSG_IDLE_VCS5,
+ [VCS6] = MSG_IDLE_VCS6,
+ [VCS7] = MSG_IDLE_VCS7,
+ [VECS0] = MSG_IDLE_VECS0,
+ [VECS1] = MSG_IDLE_VECS1,
+ [VECS2] = MSG_IDLE_VECS2,
+ [VECS3] = MSG_IDLE_VECS3,
+ [CCS0] = MSG_IDLE_CS,
+ [CCS1] = MSG_IDLE_CS,
+ [CCS2] = MSG_IDLE_CS,
+ [CCS3] = MSG_IDLE_CS,
+ };
+ u32 val;
+
+ if (!_reg[engine->id].reg)
+ return 0;
+
+ val = intel_uncore_read(engine->uncore, _reg[engine->id]);
+
+ /* bits[29:25] & bits[13:9] >> shift */
+ return (val & (val >> 16) & MSG_IDLE_FW_MASK) >> MSG_IDLE_FW_SHIFT;
+}
+
+static void __gpm_wait_for_fw_complete(struct intel_gt *gt, u32 fw_mask)
+{
+ int ret;
+
+ /* Ensure GPM receives fw up/down after CS is stopped */
+ udelay(1);
+
+ /* Wait for forcewake request to complete in GPM */
+ ret = __intel_wait_for_register_fw(gt->uncore,
+ GEN9_PWRGT_DOMAIN_STATUS,
+ fw_mask, fw_mask, 5000, 0, NULL);
+
+ /* Ensure CS receives fw ack from GPM */
+ udelay(1);
+
+ if (ret)
+ GT_TRACE(gt, "Failed to complete pending forcewake %d\n", ret);
+}
+
+/*
+ * Wa_22011802037:gen12: In addition to stopping the cs, we need to wait for any
+ * pending MI_FORCE_WAKEUP requests that the CS has initiated to complete. The
+ * pending status is indicated by bits[13:9] (masked by bits[ 29:25]) in the
+ * MSG_IDLE register. There's one MSG_IDLE register per reset domain. Since we
+ * are concerned only with the gt reset here, we use a logical OR of pending
+ * forcewakeups from all reset domains and then wait for them to complete by
+ * querying PWRGT_DOMAIN_STATUS.
+ */
+void intel_engine_wait_for_pending_mi_fw(struct intel_engine_cs *engine)
+{
+ u32 fw_pending = __cs_pending_mi_force_wakes(engine);
+
+ if (fw_pending)
+ __gpm_wait_for_fw_complete(engine->gt, fw_pending);
+}
+
static u32
read_subslice_reg(const struct intel_engine_cs *engine,
int slice, int subslice, i915_reg_t reg)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 86f7a9ac1c39..e139dc1e44eb 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -2958,6 +2958,13 @@ static void execlists_reset_prepare(struct intel_engine_cs *engine)
ring_set_paused(engine, 1);
intel_engine_stop_cs(engine);
+ /*
+ * Wa_22011802037:gen11/gen12: In addition to stopping the cs, we need
+ * to wait for any pending mi force wakeups
+ */
+ if (GRAPHICS_VER(engine->i915) == 11 || GRAPHICS_VER(engine->i915) == 12)
+ intel_engine_wait_for_pending_mi_fw(engine);
+
engine->execlists.reset_ccid = active_ccid(engine);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 5423bfd301ad..75884e0a552e 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -323,6 +323,13 @@ static void reset_prepare(struct intel_engine_cs *engine)
ENGINE_TRACE(engine, "\n");
intel_engine_stop_cs(engine);
+ /*
+ * Wa_22011802037:gen11/gen12: In addition to stopping the cs, we need
+ * to wait for any pending mi force wakeups
+ */
+ if (GRAPHICS_VER(engine->i915) == 11 || GRAPHICS_VER(engine->i915) == 12)
+ intel_engine_wait_for_pending_mi_fw(engine);
+
if (!stop_ring(engine)) {
/* G45 ring initialization often fails to reset head to zero */
ENGINE_TRACE(engine,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 2c4ad4a65089..f69a9464585e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -310,8 +310,8 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
if (IS_DG2(gt->i915))
flags |= GUC_WA_DUAL_QUEUE;
- /* Wa_22011802037: graphics version 12 */
- if (GRAPHICS_VER(gt->i915) == 12)
+ /* Wa_22011802037: graphics version 11/12 */
+ if (GRAPHICS_VER(gt->i915) == 11 || GRAPHICS_VER(gt->i915) == 12)
flags |= GUC_WA_PRE_PARSER;
/* Wa_16011777198:dg2 */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 75291e9846c5..a3fe832eff0d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1527,87 +1527,18 @@ static void guc_reset_state(struct intel_context *ce, u32 head, bool scrub)
lrc_update_regs(ce, engine, head);
}
-static u32 __cs_pending_mi_force_wakes(struct intel_engine_cs *engine)
-{
- static const i915_reg_t _reg[I915_NUM_ENGINES] = {
- [RCS0] = MSG_IDLE_CS,
- [BCS0] = MSG_IDLE_BCS,
- [VCS0] = MSG_IDLE_VCS0,
- [VCS1] = MSG_IDLE_VCS1,
- [VCS2] = MSG_IDLE_VCS2,
- [VCS3] = MSG_IDLE_VCS3,
- [VCS4] = MSG_IDLE_VCS4,
- [VCS5] = MSG_IDLE_VCS5,
- [VCS6] = MSG_IDLE_VCS6,
- [VCS7] = MSG_IDLE_VCS7,
- [VECS0] = MSG_IDLE_VECS0,
- [VECS1] = MSG_IDLE_VECS1,
- [VECS2] = MSG_IDLE_VECS2,
- [VECS3] = MSG_IDLE_VECS3,
- [CCS0] = MSG_IDLE_CS,
- [CCS1] = MSG_IDLE_CS,
- [CCS2] = MSG_IDLE_CS,
- [CCS3] = MSG_IDLE_CS,
- };
- u32 val;
-
- if (!_reg[engine->id].reg)
- return 0;
-
- val = intel_uncore_read(engine->uncore, _reg[engine->id]);
-
- /* bits[29:25] & bits[13:9] >> shift */
- return (val & (val >> 16) & MSG_IDLE_FW_MASK) >> MSG_IDLE_FW_SHIFT;
-}
-
-static void __gpm_wait_for_fw_complete(struct intel_gt *gt, u32 fw_mask)
-{
- int ret;
-
- /* Ensure GPM receives fw up/down after CS is stopped */
- udelay(1);
-
- /* Wait for forcewake request to complete in GPM */
- ret = __intel_wait_for_register_fw(gt->uncore,
- GEN9_PWRGT_DOMAIN_STATUS,
- fw_mask, fw_mask, 5000, 0, NULL);
-
- /* Ensure CS receives fw ack from GPM */
- udelay(1);
-
- if (ret)
- GT_TRACE(gt, "Failed to complete pending forcewake %d\n", ret);
-}
-
-/*
- * Wa_22011802037:gen12: In addition to stopping the cs, we need to wait for any
- * pending MI_FORCE_WAKEUP requests that the CS has initiated to complete. The
- * pending status is indicated by bits[13:9] (masked by bits[ 29:25]) in the
- * MSG_IDLE register. There's one MSG_IDLE register per reset domain. Since we
- * are concerned only with the gt reset here, we use a logical OR of pending
- * forcewakeups from all reset domains and then wait for them to complete by
- * querying PWRGT_DOMAIN_STATUS.
- */
static void guc_engine_reset_prepare(struct intel_engine_cs *engine)
{
- u32 fw_pending;
-
- if (GRAPHICS_VER(engine->i915) != 12)
+ if (GRAPHICS_VER(engine->i915) != 11 && GRAPHICS_VER(engine->i915) != 12)
return;
- /*
- * Wa_22011802037
- * TODO: Occasionally trying to stop the cs times out, but does not
- * adversely affect functionality. The timeout is set as a config
- * parameter that defaults to 100ms. Assuming that this timeout is
- * sufficient for any pending MI_FORCEWAKEs to complete, ignore the
- * timeout returned here until it is root caused.
- */
intel_engine_stop_cs(engine);
- fw_pending = __cs_pending_mi_force_wakes(engine);
- if (fw_pending)
- __gpm_wait_for_fw_complete(engine->gt, fw_pending);
+ /*
+ * Wa_22011802037:gen11/gen12: In addition to stopping the cs, we need
+ * to wait for any pending mi force wakeups
+ */
+ intel_engine_wait_for_pending_mi_fw(engine);
}
static void guc_reset_nop(struct intel_engine_cs *engine)
--
2.35.1
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
2022-05-02 22:18 [Intel-gfx] [PATCH] drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend Umesh Nerlige Ramappa
@ 2022-05-02 23:19 ` Patchwork
2022-05-02 23:41 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-05-03 8:42 ` [Intel-gfx] [PATCH] " Tvrtko Ursulin
2 siblings, 0 replies; 11+ messages in thread
From: Patchwork @ 2022-05-02 23:19 UTC (permalink / raw)
To: Umesh Nerlige Ramappa; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
URL : https://patchwork.freedesktop.org/series/103461/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
2022-05-02 22:18 [Intel-gfx] [PATCH] drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend Umesh Nerlige Ramappa
2022-05-02 23:19 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for " Patchwork
@ 2022-05-02 23:41 ` Patchwork
2022-05-03 8:42 ` [Intel-gfx] [PATCH] " Tvrtko Ursulin
2 siblings, 0 replies; 11+ messages in thread
From: Patchwork @ 2022-05-02 23:41 UTC (permalink / raw)
To: Umesh Nerlige Ramappa; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 4870 bytes --]
== Series Details ==
Series: drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
URL : https://patchwork.freedesktop.org/series/103461/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11589 -> Patchwork_103461v1
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_103461v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_103461v1, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103461v1/index.html
Participating hosts (41 -> 40)
------------------------------
Additional (1): fi-pnv-d510
Missing (2): fi-bsw-cyan bat-dg1-5
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_103461v1:
### IGT changes ###
#### Possible regressions ####
* igt@i915_selftest@live@memory_region:
- fi-cfl-8109u: [PASS][1] -> [DMESG-WARN][2] +29 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11589/fi-cfl-8109u/igt@i915_selftest@live@memory_region.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103461v1/fi-cfl-8109u/igt@i915_selftest@live@memory_region.html
Known issues
------------
Here are the changes found in Patchwork_103461v1 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@i915_pm_rpm@module-reload:
- fi-cfl-8109u: [PASS][3] -> [DMESG-FAIL][4] ([i915#62])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11589/fi-cfl-8109u/igt@i915_pm_rpm@module-reload.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103461v1/fi-cfl-8109u/igt@i915_pm_rpm@module-reload.html
* igt@i915_selftest@live@gt_lrc:
- fi-bsw-n3050: [PASS][5] -> [DMESG-FAIL][6] ([i915#2373])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11589/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103461v1/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@gtt:
- fi-bdw-5557u: [PASS][7] -> [DMESG-FAIL][8] ([i915#3674])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11589/fi-bdw-5557u/igt@i915_selftest@live@gtt.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103461v1/fi-bdw-5557u/igt@i915_selftest@live@gtt.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u: [PASS][9] -> [DMESG-WARN][10] ([i915#62]) +15 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11589/fi-cfl-8109u/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103461v1/fi-cfl-8109u/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b.html
* igt@prime_vgem@basic-userptr:
- fi-pnv-d510: NOTRUN -> [SKIP][11] ([fdo#109271]) +40 similar issues
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103461v1/fi-pnv-d510/igt@prime_vgem@basic-userptr.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2373]: https://gitlab.freedesktop.org/drm/intel/issues/2373
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#3674]: https://gitlab.freedesktop.org/drm/intel/issues/3674
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
Build changes
-------------
* Linux: CI_DRM_11589 -> Patchwork_103461v1
CI-20190529: 20190529
CI_DRM_11589: 1edbec0199f3254f1bcf585b3865452d4c931c3d @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6464: eddc67c5c85b8ee6eb4d13752ca43da5073dc985 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_103461v1: 1edbec0199f3254f1bcf585b3865452d4c931c3d @ git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
934af673eb23 drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103461v1/index.html
[-- Attachment #2: Type: text/html, Size: 5099 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
2022-05-02 22:18 [Intel-gfx] [PATCH] drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend Umesh Nerlige Ramappa
2022-05-02 23:19 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for " Patchwork
2022-05-02 23:41 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
@ 2022-05-03 8:42 ` Tvrtko Ursulin
2022-05-03 19:49 ` Umesh Nerlige Ramappa
2 siblings, 1 reply; 11+ messages in thread
From: Tvrtko Ursulin @ 2022-05-03 8:42 UTC (permalink / raw)
To: Umesh Nerlige Ramappa, intel-gfx, daniele.ceraolospurio
On 02/05/2022 23:18, Umesh Nerlige Ramappa wrote:
> Current implementation of Wa_22011802037 is limited to the GuC backend
> and gen12. Add support for execlist backend and gen11 as well.
Is the implication f6aa0d713c88 ("drm/i915: Add Wa_22011802037 force cs
halt") does not work on Tigerlake? Fixes: tag probably required in that
case since I have sold that fix as a, well, fix.
> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
> ---
> drivers/gpu/drm/i915/gt/intel_engine.h | 2 +
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 81 ++++++++++++++++++-
> .../drm/i915/gt/intel_execlists_submission.c | 7 ++
> .../gpu/drm/i915/gt/intel_ring_submission.c | 7 ++
> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 +-
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 81 ++-----------------
> 6 files changed, 103 insertions(+), 79 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h b/drivers/gpu/drm/i915/gt/intel_engine.h
> index 1431f1e9dbee..04e435bce79b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> @@ -201,6 +201,8 @@ int intel_ring_submission_setup(struct intel_engine_cs *engine);
> int intel_engine_stop_cs(struct intel_engine_cs *engine);
> void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
>
> +void intel_engine_wait_for_pending_mi_fw(struct intel_engine_cs *engine);
> +
> void intel_engine_set_hwsp_writemask(struct intel_engine_cs *engine, u32 mask);
>
> u64 intel_engine_get_active_head(const struct intel_engine_cs *engine);
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 14c6ddbbfde8..0bda665a407c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1282,10 +1282,10 @@ static int __intel_engine_stop_cs(struct intel_engine_cs *engine,
> intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
>
> /*
> - * Wa_22011802037 : gen12, Prior to doing a reset, ensure CS is
> + * Wa_22011802037 : gen11, gen12, Prior to doing a reset, ensure CS is
> * stopped, set ring stop bit and prefetch disable bit to halt CS
> */
> - if (GRAPHICS_VER(engine->i915) == 12)
> + if (GRAPHICS_VER(engine->i915) == 11 || GRAPHICS_VER(engine->i915) == 12)
IS_GRAPHICS_VER(11, 12)
> intel_uncore_write_fw(uncore, RING_MODE_GEN7(engine->mmio_base),
> _MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));
>
> @@ -1308,6 +1308,14 @@ int intel_engine_stop_cs(struct intel_engine_cs *engine)
> return -ENODEV;
>
> ENGINE_TRACE(engine, "\n");
> + /*
> + * TODO: Occasionally trying to stop the cs times out, but does not
What is the TODO part? To figure out why is sometimes does not work?
> + * adversely affect functionality. The timeout is set as a config
> + * parameter that defaults to 100ms. Assuming that this timeout is
> + * sufficient for any pending MI_FORCEWAKEs to complete. Once root
> + * caused, the caller must check and handler the return from this
s/handler/handle/
TODO is to convert the function to return an error?
> + * function.
> + */
> if (__intel_engine_stop_cs(engine, 1000, stop_timeout(engine))) {
> ENGINE_TRACE(engine,
> "timed out on STOP_RING -> IDLE; HEAD:%04x, TAIL:%04x\n",
> @@ -1334,6 +1342,75 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine)
> ENGINE_WRITE_FW(engine, RING_MI_MODE, _MASKED_BIT_DISABLE(STOP_RING));
> }
>
> +static u32 __cs_pending_mi_force_wakes(struct intel_engine_cs *engine)
> +{
> + static const i915_reg_t _reg[I915_NUM_ENGINES] = {
> + [RCS0] = MSG_IDLE_CS,
> + [BCS0] = MSG_IDLE_BCS,
> + [VCS0] = MSG_IDLE_VCS0,
> + [VCS1] = MSG_IDLE_VCS1,
> + [VCS2] = MSG_IDLE_VCS2,
> + [VCS3] = MSG_IDLE_VCS3,
> + [VCS4] = MSG_IDLE_VCS4,
> + [VCS5] = MSG_IDLE_VCS5,
> + [VCS6] = MSG_IDLE_VCS6,
> + [VCS7] = MSG_IDLE_VCS7,
> + [VECS0] = MSG_IDLE_VECS0,
> + [VECS1] = MSG_IDLE_VECS1,
> + [VECS2] = MSG_IDLE_VECS2,
> + [VECS3] = MSG_IDLE_VECS3,
> + [CCS0] = MSG_IDLE_CS,
> + [CCS1] = MSG_IDLE_CS,
> + [CCS2] = MSG_IDLE_CS,
> + [CCS3] = MSG_IDLE_CS,
> + };
> + u32 val;
> +
> + if (!_reg[engine->id].reg)
> + return 0;
> +
> + val = intel_uncore_read(engine->uncore, _reg[engine->id]);
> +
> + /* bits[29:25] & bits[13:9] >> shift */
> + return (val & (val >> 16) & MSG_IDLE_FW_MASK) >> MSG_IDLE_FW_SHIFT;
> +}
> +
> +static void __gpm_wait_for_fw_complete(struct intel_gt *gt, u32 fw_mask)
> +{
> + int ret;
> +
> + /* Ensure GPM receives fw up/down after CS is stopped */
> + udelay(1);
What's with the udealys in here when __intel_wait_for_register_fw
already does some waiting?
> +
> + /* Wait for forcewake request to complete in GPM */
> + ret = __intel_wait_for_register_fw(gt->uncore,
> + GEN9_PWRGT_DOMAIN_STATUS,
> + fw_mask, fw_mask, 5000, 0, NULL);
> +
> + /* Ensure CS receives fw ack from GPM */
> + udelay(1);
> +
> + if (ret)
> + GT_TRACE(gt, "Failed to complete pending forcewake %d\n", ret);
> +}
> +
> +/*
> + * Wa_22011802037:gen12: In addition to stopping the cs, we need to wait for any
> + * pending MI_FORCE_WAKEUP requests that the CS has initiated to complete. The
> + * pending status is indicated by bits[13:9] (masked by bits[ 29:25]) in the
Extra space in square brackets.
> + * MSG_IDLE register. There's one MSG_IDLE register per reset domain. Since we
> + * are concerned only with the gt reset here, we use a logical OR of pending
> + * forcewakeups from all reset domains and then wait for them to complete by
> + * querying PWRGT_DOMAIN_STATUS.
> + */
> +void intel_engine_wait_for_pending_mi_fw(struct intel_engine_cs *engine)
> +{
> + u32 fw_pending = __cs_pending_mi_force_wakes(engine);
> +
> + if (fw_pending)
> + __gpm_wait_for_fw_complete(engine->gt, fw_pending);
> +}
> +
> static u32
> read_subslice_reg(const struct intel_engine_cs *engine,
> int slice, int subslice, i915_reg_t reg)
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 86f7a9ac1c39..e139dc1e44eb 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -2958,6 +2958,13 @@ static void execlists_reset_prepare(struct intel_engine_cs *engine)
> ring_set_paused(engine, 1);
> intel_engine_stop_cs(engine);
>
> + /*
> + * Wa_22011802037:gen11/gen12: In addition to stopping the cs, we need
> + * to wait for any pending mi force wakeups
> + */
> + if (GRAPHICS_VER(engine->i915) == 11 || GRAPHICS_VER(engine->i915) == 12)
> + intel_engine_wait_for_pending_mi_fw(engine);
> +
> engine->execlists.reset_ccid = active_ccid(engine);
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> index 5423bfd301ad..75884e0a552e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> @@ -323,6 +323,13 @@ static void reset_prepare(struct intel_engine_cs *engine)
> ENGINE_TRACE(engine, "\n");
> intel_engine_stop_cs(engine);
>
> + /*
> + * Wa_22011802037:gen11/gen12: In addition to stopping the cs, we need
> + * to wait for any pending mi force wakeups
> + */
> + if (GRAPHICS_VER(engine->i915) == 11 || GRAPHICS_VER(engine->i915) == 12)
IS_GRAPHICS_VER
> + intel_engine_wait_for_pending_mi_fw(engine);
> +
> if (!stop_ring(engine)) {
> /* G45 ring initialization often fails to reset head to zero */
> ENGINE_TRACE(engine,
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index 2c4ad4a65089..f69a9464585e 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -310,8 +310,8 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
> if (IS_DG2(gt->i915))
> flags |= GUC_WA_DUAL_QUEUE;
>
> - /* Wa_22011802037: graphics version 12 */
> - if (GRAPHICS_VER(gt->i915) == 12)
> + /* Wa_22011802037: graphics version 11/12 */
> + if (GRAPHICS_VER(gt->i915) == 11 || GRAPHICS_VER(gt->i915) == 12)
Ditto.
> flags |= GUC_WA_PRE_PARSER;
>
> /* Wa_16011777198:dg2 */
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 75291e9846c5..a3fe832eff0d 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -1527,87 +1527,18 @@ static void guc_reset_state(struct intel_context *ce, u32 head, bool scrub)
> lrc_update_regs(ce, engine, head);
> }
>
> -static u32 __cs_pending_mi_force_wakes(struct intel_engine_cs *engine)
> -{
> - static const i915_reg_t _reg[I915_NUM_ENGINES] = {
> - [RCS0] = MSG_IDLE_CS,
> - [BCS0] = MSG_IDLE_BCS,
> - [VCS0] = MSG_IDLE_VCS0,
> - [VCS1] = MSG_IDLE_VCS1,
> - [VCS2] = MSG_IDLE_VCS2,
> - [VCS3] = MSG_IDLE_VCS3,
> - [VCS4] = MSG_IDLE_VCS4,
> - [VCS5] = MSG_IDLE_VCS5,
> - [VCS6] = MSG_IDLE_VCS6,
> - [VCS7] = MSG_IDLE_VCS7,
> - [VECS0] = MSG_IDLE_VECS0,
> - [VECS1] = MSG_IDLE_VECS1,
> - [VECS2] = MSG_IDLE_VECS2,
> - [VECS3] = MSG_IDLE_VECS3,
> - [CCS0] = MSG_IDLE_CS,
> - [CCS1] = MSG_IDLE_CS,
> - [CCS2] = MSG_IDLE_CS,
> - [CCS3] = MSG_IDLE_CS,
> - };
> - u32 val;
> -
> - if (!_reg[engine->id].reg)
> - return 0;
> -
> - val = intel_uncore_read(engine->uncore, _reg[engine->id]);
> -
> - /* bits[29:25] & bits[13:9] >> shift */
> - return (val & (val >> 16) & MSG_IDLE_FW_MASK) >> MSG_IDLE_FW_SHIFT;
> -}
> -
> -static void __gpm_wait_for_fw_complete(struct intel_gt *gt, u32 fw_mask)
> -{
> - int ret;
> -
> - /* Ensure GPM receives fw up/down after CS is stopped */
> - udelay(1);
> -
> - /* Wait for forcewake request to complete in GPM */
> - ret = __intel_wait_for_register_fw(gt->uncore,
> - GEN9_PWRGT_DOMAIN_STATUS,
> - fw_mask, fw_mask, 5000, 0, NULL);
> -
> - /* Ensure CS receives fw ack from GPM */
> - udelay(1);
> -
> - if (ret)
> - GT_TRACE(gt, "Failed to complete pending forcewake %d\n", ret);
> -}
> -
> -/*
> - * Wa_22011802037:gen12: In addition to stopping the cs, we need to wait for any
> - * pending MI_FORCE_WAKEUP requests that the CS has initiated to complete. The
> - * pending status is indicated by bits[13:9] (masked by bits[ 29:25]) in the
> - * MSG_IDLE register. There's one MSG_IDLE register per reset domain. Since we
> - * are concerned only with the gt reset here, we use a logical OR of pending
> - * forcewakeups from all reset domains and then wait for them to complete by
> - * querying PWRGT_DOMAIN_STATUS.
> - */
> static void guc_engine_reset_prepare(struct intel_engine_cs *engine)
> {
> - u32 fw_pending;
> -
> - if (GRAPHICS_VER(engine->i915) != 12)
> + if (GRAPHICS_VER(engine->i915) != 11 && GRAPHICS_VER(engine->i915) != 12)
!IS_GRAPHICS_VER
> return;
>
> - /*
> - * Wa_22011802037
> - * TODO: Occasionally trying to stop the cs times out, but does not
> - * adversely affect functionality. The timeout is set as a config
> - * parameter that defaults to 100ms. Assuming that this timeout is
> - * sufficient for any pending MI_FORCEWAKEs to complete, ignore the
> - * timeout returned here until it is root caused.
> - */
> intel_engine_stop_cs(engine);
>
> - fw_pending = __cs_pending_mi_force_wakes(engine);
> - if (fw_pending)
> - __gpm_wait_for_fw_complete(engine->gt, fw_pending);
> + /*
> + * Wa_22011802037:gen11/gen12: In addition to stopping the cs, we need
> + * to wait for any pending mi force wakeups
> + */
> + intel_engine_wait_for_pending_mi_fw(engine);
> }
>
> static void guc_reset_nop(struct intel_engine_cs *engine)
Regards,
Tvrtko
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
2022-05-03 8:42 ` [Intel-gfx] [PATCH] " Tvrtko Ursulin
@ 2022-05-03 19:49 ` Umesh Nerlige Ramappa
2022-05-04 8:10 ` Tvrtko Ursulin
0 siblings, 1 reply; 11+ messages in thread
From: Umesh Nerlige Ramappa @ 2022-05-03 19:49 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: intel-gfx
On Tue, May 03, 2022 at 09:42:52AM +0100, Tvrtko Ursulin wrote:
>
>On 02/05/2022 23:18, Umesh Nerlige Ramappa wrote:
>>Current implementation of Wa_22011802037 is limited to the GuC backend
>>and gen12. Add support for execlist backend and gen11 as well.
>
>Is the implication f6aa0d713c88 ("drm/i915: Add Wa_22011802037 force
>cs halt") does not work on Tigerlake? Fixes: tag probably required in
>that case since I have sold that fix as a, well, fix.
After the fix was made, the WA has evolved and added some more steps for
handling pending MI_FORCE_WAKEs. This patch is the additional set of
steps needed for the WA. As you mentioned offline, I should correct the
commit message to indicate that the WA does exist for execlists, but
needs additional steps. Will add Fixes: tag.
>
>>Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>>---
>> drivers/gpu/drm/i915/gt/intel_engine.h | 2 +
>> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 81 ++++++++++++++++++-
>> .../drm/i915/gt/intel_execlists_submission.c | 7 ++
>> .../gpu/drm/i915/gt/intel_ring_submission.c | 7 ++
>> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 +-
>> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 81 ++-----------------
>> 6 files changed, 103 insertions(+), 79 deletions(-)
>>
>>diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h b/drivers/gpu/drm/i915/gt/intel_engine.h
>>index 1431f1e9dbee..04e435bce79b 100644
>>--- a/drivers/gpu/drm/i915/gt/intel_engine.h
>>+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
>>@@ -201,6 +201,8 @@ int intel_ring_submission_setup(struct intel_engine_cs *engine);
>> int intel_engine_stop_cs(struct intel_engine_cs *engine);
>> void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
>>+void intel_engine_wait_for_pending_mi_fw(struct intel_engine_cs *engine);
>>+
>> void intel_engine_set_hwsp_writemask(struct intel_engine_cs *engine, u32 mask);
>> u64 intel_engine_get_active_head(const struct intel_engine_cs *engine);
>>diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>index 14c6ddbbfde8..0bda665a407c 100644
>>--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>@@ -1282,10 +1282,10 @@ static int __intel_engine_stop_cs(struct intel_engine_cs *engine,
>> intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
>> /*
>>- * Wa_22011802037 : gen12, Prior to doing a reset, ensure CS is
>>+ * Wa_22011802037 : gen11, gen12, Prior to doing a reset, ensure CS is
>> * stopped, set ring stop bit and prefetch disable bit to halt CS
>> */
>>- if (GRAPHICS_VER(engine->i915) == 12)
>>+ if (GRAPHICS_VER(engine->i915) == 11 || GRAPHICS_VER(engine->i915) == 12)
>
>IS_GRAPHICS_VER(11, 12)
>
>> intel_uncore_write_fw(uncore, RING_MODE_GEN7(engine->mmio_base),
>> _MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));
>>@@ -1308,6 +1308,14 @@ int intel_engine_stop_cs(struct intel_engine_cs *engine)
>> return -ENODEV;
>> ENGINE_TRACE(engine, "\n");
>>+ /*
>>+ * TODO: Occasionally trying to stop the cs times out, but does not
>
>What is the TODO part? To figure out why is sometimes does not work?
>
>>+ * adversely affect functionality. The timeout is set as a config
>>+ * parameter that defaults to 100ms. Assuming that this timeout is
>>+ * sufficient for any pending MI_FORCEWAKEs to complete. Once root
>>+ * caused, the caller must check and handler the return from this
>
>s/handler/handle/
>
>TODO is to convert the function to return an error?
TODO: Find out why occasionally stopping the CS times out. Seen
especially with gem_eio tests.
I will update the comment to be clear.
>
>>+ * function.
>>+ */
>> if (__intel_engine_stop_cs(engine, 1000, stop_timeout(engine))) {
>> ENGINE_TRACE(engine,
>> "timed out on STOP_RING -> IDLE; HEAD:%04x, TAIL:%04x\n",
>>@@ -1334,6 +1342,75 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine)
>> ENGINE_WRITE_FW(engine, RING_MI_MODE, _MASKED_BIT_DISABLE(STOP_RING));
>> }
>>+static u32 __cs_pending_mi_force_wakes(struct intel_engine_cs *engine)
>>+{
>>+ static const i915_reg_t _reg[I915_NUM_ENGINES] = {
>>+ [RCS0] = MSG_IDLE_CS,
>>+ [BCS0] = MSG_IDLE_BCS,
>>+ [VCS0] = MSG_IDLE_VCS0,
>>+ [VCS1] = MSG_IDLE_VCS1,
>>+ [VCS2] = MSG_IDLE_VCS2,
>>+ [VCS3] = MSG_IDLE_VCS3,
>>+ [VCS4] = MSG_IDLE_VCS4,
>>+ [VCS5] = MSG_IDLE_VCS5,
>>+ [VCS6] = MSG_IDLE_VCS6,
>>+ [VCS7] = MSG_IDLE_VCS7,
>>+ [VECS0] = MSG_IDLE_VECS0,
>>+ [VECS1] = MSG_IDLE_VECS1,
>>+ [VECS2] = MSG_IDLE_VECS2,
>>+ [VECS3] = MSG_IDLE_VECS3,
>>+ [CCS0] = MSG_IDLE_CS,
>>+ [CCS1] = MSG_IDLE_CS,
>>+ [CCS2] = MSG_IDLE_CS,
>>+ [CCS3] = MSG_IDLE_CS,
>>+ };
>>+ u32 val;
>>+
>>+ if (!_reg[engine->id].reg)
>>+ return 0;
>>+
>>+ val = intel_uncore_read(engine->uncore, _reg[engine->id]);
>>+
>>+ /* bits[29:25] & bits[13:9] >> shift */
>>+ return (val & (val >> 16) & MSG_IDLE_FW_MASK) >> MSG_IDLE_FW_SHIFT;
>>+}
>>+
>>+static void __gpm_wait_for_fw_complete(struct intel_gt *gt, u32 fw_mask)
>>+{
>>+ int ret;
>>+
>>+ /* Ensure GPM receives fw up/down after CS is stopped */
>>+ udelay(1);
>
>What's with the udealys in here when __intel_wait_for_register_fw
>already does some waiting?
Once idle, the WA instructs us to wait 1us around checking this status.
The assumption here is that __intel_wait_for_register_fw could just exit
as soon as the condition is met by HW.
Thanks,
Umesh
>
>>+
>>+ /* Wait for forcewake request to complete in GPM */
>>+ ret = __intel_wait_for_register_fw(gt->uncore,
>>+ GEN9_PWRGT_DOMAIN_STATUS,
>>+ fw_mask, fw_mask, 5000, 0, NULL);
>>+
>>+ /* Ensure CS receives fw ack from GPM */
>>+ udelay(1);
>>+
>>+ if (ret)
>>+ GT_TRACE(gt, "Failed to complete pending forcewake %d\n", ret);
>>+}
>>+
>>+/*
>>+ * Wa_22011802037:gen12: In addition to stopping the cs, we need to wait for any
>>+ * pending MI_FORCE_WAKEUP requests that the CS has initiated to complete. The
>>+ * pending status is indicated by bits[13:9] (masked by bits[ 29:25]) in the
>
>Extra space in square brackets.
>
>>+ * MSG_IDLE register. There's one MSG_IDLE register per reset domain. Since we
>>+ * are concerned only with the gt reset here, we use a logical OR of pending
>>+ * forcewakeups from all reset domains and then wait for them to complete by
>>+ * querying PWRGT_DOMAIN_STATUS.
>>+ */
>>+void intel_engine_wait_for_pending_mi_fw(struct intel_engine_cs *engine)
>>+{
>>+ u32 fw_pending = __cs_pending_mi_force_wakes(engine);
>>+
>>+ if (fw_pending)
>>+ __gpm_wait_for_fw_complete(engine->gt, fw_pending);
>>+}
>>+
>> static u32
>> read_subslice_reg(const struct intel_engine_cs *engine,
>> int slice, int subslice, i915_reg_t reg)
>>diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>index 86f7a9ac1c39..e139dc1e44eb 100644
>>--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>@@ -2958,6 +2958,13 @@ static void execlists_reset_prepare(struct intel_engine_cs *engine)
>> ring_set_paused(engine, 1);
>> intel_engine_stop_cs(engine);
>>+ /*
>>+ * Wa_22011802037:gen11/gen12: In addition to stopping the cs, we need
>>+ * to wait for any pending mi force wakeups
>>+ */
>>+ if (GRAPHICS_VER(engine->i915) == 11 || GRAPHICS_VER(engine->i915) == 12)
>>+ intel_engine_wait_for_pending_mi_fw(engine);
>>+
>> engine->execlists.reset_ccid = active_ccid(engine);
>> }
>>diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>index 5423bfd301ad..75884e0a552e 100644
>>--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>@@ -323,6 +323,13 @@ static void reset_prepare(struct intel_engine_cs *engine)
>> ENGINE_TRACE(engine, "\n");
>> intel_engine_stop_cs(engine);
>>+ /*
>>+ * Wa_22011802037:gen11/gen12: In addition to stopping the cs, we need
>>+ * to wait for any pending mi force wakeups
>>+ */
>>+ if (GRAPHICS_VER(engine->i915) == 11 || GRAPHICS_VER(engine->i915) == 12)
>
>IS_GRAPHICS_VER
>
>>+ intel_engine_wait_for_pending_mi_fw(engine);
>>+
>> if (!stop_ring(engine)) {
>> /* G45 ring initialization often fails to reset head to zero */
>> ENGINE_TRACE(engine,
>>diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>index 2c4ad4a65089..f69a9464585e 100644
>>--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>@@ -310,8 +310,8 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
>> if (IS_DG2(gt->i915))
>> flags |= GUC_WA_DUAL_QUEUE;
>>- /* Wa_22011802037: graphics version 12 */
>>- if (GRAPHICS_VER(gt->i915) == 12)
>>+ /* Wa_22011802037: graphics version 11/12 */
>>+ if (GRAPHICS_VER(gt->i915) == 11 || GRAPHICS_VER(gt->i915) == 12)
>
>Ditto.
>
>> flags |= GUC_WA_PRE_PARSER;
>> /* Wa_16011777198:dg2 */
>>diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>index 75291e9846c5..a3fe832eff0d 100644
>>--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>@@ -1527,87 +1527,18 @@ static void guc_reset_state(struct intel_context *ce, u32 head, bool scrub)
>> lrc_update_regs(ce, engine, head);
>> }
>>-static u32 __cs_pending_mi_force_wakes(struct intel_engine_cs *engine)
>>-{
>>- static const i915_reg_t _reg[I915_NUM_ENGINES] = {
>>- [RCS0] = MSG_IDLE_CS,
>>- [BCS0] = MSG_IDLE_BCS,
>>- [VCS0] = MSG_IDLE_VCS0,
>>- [VCS1] = MSG_IDLE_VCS1,
>>- [VCS2] = MSG_IDLE_VCS2,
>>- [VCS3] = MSG_IDLE_VCS3,
>>- [VCS4] = MSG_IDLE_VCS4,
>>- [VCS5] = MSG_IDLE_VCS5,
>>- [VCS6] = MSG_IDLE_VCS6,
>>- [VCS7] = MSG_IDLE_VCS7,
>>- [VECS0] = MSG_IDLE_VECS0,
>>- [VECS1] = MSG_IDLE_VECS1,
>>- [VECS2] = MSG_IDLE_VECS2,
>>- [VECS3] = MSG_IDLE_VECS3,
>>- [CCS0] = MSG_IDLE_CS,
>>- [CCS1] = MSG_IDLE_CS,
>>- [CCS2] = MSG_IDLE_CS,
>>- [CCS3] = MSG_IDLE_CS,
>>- };
>>- u32 val;
>>-
>>- if (!_reg[engine->id].reg)
>>- return 0;
>>-
>>- val = intel_uncore_read(engine->uncore, _reg[engine->id]);
>>-
>>- /* bits[29:25] & bits[13:9] >> shift */
>>- return (val & (val >> 16) & MSG_IDLE_FW_MASK) >> MSG_IDLE_FW_SHIFT;
>>-}
>>-
>>-static void __gpm_wait_for_fw_complete(struct intel_gt *gt, u32 fw_mask)
>>-{
>>- int ret;
>>-
>>- /* Ensure GPM receives fw up/down after CS is stopped */
>>- udelay(1);
>>-
>>- /* Wait for forcewake request to complete in GPM */
>>- ret = __intel_wait_for_register_fw(gt->uncore,
>>- GEN9_PWRGT_DOMAIN_STATUS,
>>- fw_mask, fw_mask, 5000, 0, NULL);
>>-
>>- /* Ensure CS receives fw ack from GPM */
>>- udelay(1);
>>-
>>- if (ret)
>>- GT_TRACE(gt, "Failed to complete pending forcewake %d\n", ret);
>>-}
>>-
>>-/*
>>- * Wa_22011802037:gen12: In addition to stopping the cs, we need to wait for any
>>- * pending MI_FORCE_WAKEUP requests that the CS has initiated to complete. The
>>- * pending status is indicated by bits[13:9] (masked by bits[ 29:25]) in the
>>- * MSG_IDLE register. There's one MSG_IDLE register per reset domain. Since we
>>- * are concerned only with the gt reset here, we use a logical OR of pending
>>- * forcewakeups from all reset domains and then wait for them to complete by
>>- * querying PWRGT_DOMAIN_STATUS.
>>- */
>> static void guc_engine_reset_prepare(struct intel_engine_cs *engine)
>> {
>>- u32 fw_pending;
>>-
>>- if (GRAPHICS_VER(engine->i915) != 12)
>>+ if (GRAPHICS_VER(engine->i915) != 11 && GRAPHICS_VER(engine->i915) != 12)
>
>!IS_GRAPHICS_VER
>
>> return;
>>- /*
>>- * Wa_22011802037
>>- * TODO: Occasionally trying to stop the cs times out, but does not
>>- * adversely affect functionality. The timeout is set as a config
>>- * parameter that defaults to 100ms. Assuming that this timeout is
>>- * sufficient for any pending MI_FORCEWAKEs to complete, ignore the
>>- * timeout returned here until it is root caused.
>>- */
>> intel_engine_stop_cs(engine);
>>- fw_pending = __cs_pending_mi_force_wakes(engine);
>>- if (fw_pending)
>>- __gpm_wait_for_fw_complete(engine->gt, fw_pending);
>>+ /*
>>+ * Wa_22011802037:gen11/gen12: In addition to stopping the cs, we need
>>+ * to wait for any pending mi force wakeups
>>+ */
>>+ intel_engine_wait_for_pending_mi_fw(engine);
>> }
>> static void guc_reset_nop(struct intel_engine_cs *engine)
>
>Regards,
>
>Tvrtko
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
2022-05-03 19:49 ` Umesh Nerlige Ramappa
@ 2022-05-04 8:10 ` Tvrtko Ursulin
2022-05-04 17:35 ` Umesh Nerlige Ramappa
0 siblings, 1 reply; 11+ messages in thread
From: Tvrtko Ursulin @ 2022-05-04 8:10 UTC (permalink / raw)
To: Umesh Nerlige Ramappa; +Cc: intel-gfx
On 03/05/2022 20:49, Umesh Nerlige Ramappa wrote:
> On Tue, May 03, 2022 at 09:42:52AM +0100, Tvrtko Ursulin wrote:
>>
>> On 02/05/2022 23:18, Umesh Nerlige Ramappa wrote:
>>> Current implementation of Wa_22011802037 is limited to the GuC backend
>>> and gen12. Add support for execlist backend and gen11 as well.
>>
>> Is the implication f6aa0d713c88 ("drm/i915: Add Wa_22011802037 force
>> cs halt") does not work on Tigerlake? Fixes: tag probably required in
>> that case since I have sold that fix as a, well, fix.
>
> After the fix was made, the WA has evolved and added some more steps for
> handling pending MI_FORCE_WAKEs. This patch is the additional set of
> steps needed for the WA. As you mentioned offline, I should correct the
> commit message to indicate that the WA does exist for execlists, but
> needs additional steps. Will add Fixes: tag.
Ok, that would be good then since it does sound they need to be tied
together (as in cherry picked for fixes).
Will it be followed up with preempt-to-idle implementation to avoid the,
as I understand it, potential for activity on one CCS engine defeating
the WA on another by timing out the wait for idle?
>>> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>>> ---
>>> drivers/gpu/drm/i915/gt/intel_engine.h | 2 +
>>> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 81 ++++++++++++++++++-
>>> .../drm/i915/gt/intel_execlists_submission.c | 7 ++
>>> .../gpu/drm/i915/gt/intel_ring_submission.c | 7 ++
>>> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 +-
>>> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 81 ++-----------------
>>> 6 files changed, 103 insertions(+), 79 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
>>> b/drivers/gpu/drm/i915/gt/intel_engine.h
>>> index 1431f1e9dbee..04e435bce79b 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_engine.h
>>> +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
>>> @@ -201,6 +201,8 @@ int intel_ring_submission_setup(struct
>>> intel_engine_cs *engine);
>>> int intel_engine_stop_cs(struct intel_engine_cs *engine);
>>> void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
>>> +void intel_engine_wait_for_pending_mi_fw(struct intel_engine_cs
>>> *engine);
>>> +
>>> void intel_engine_set_hwsp_writemask(struct intel_engine_cs *engine,
>>> u32 mask);
>>> u64 intel_engine_get_active_head(const struct intel_engine_cs *engine);
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>> index 14c6ddbbfde8..0bda665a407c 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>> @@ -1282,10 +1282,10 @@ static int __intel_engine_stop_cs(struct
>>> intel_engine_cs *engine,
>>> intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
>>> /*
>>> - * Wa_22011802037 : gen12, Prior to doing a reset, ensure CS is
>>> + * Wa_22011802037 : gen11, gen12, Prior to doing a reset, ensure
>>> CS is
>>> * stopped, set ring stop bit and prefetch disable bit to halt CS
>>> */
>>> - if (GRAPHICS_VER(engine->i915) == 12)
>>> + if (GRAPHICS_VER(engine->i915) == 11 ||
>>> GRAPHICS_VER(engine->i915) == 12)
>>
>> IS_GRAPHICS_VER(11, 12)
>>
>>> intel_uncore_write_fw(uncore,
>>> RING_MODE_GEN7(engine->mmio_base),
>>> _MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));
>>> @@ -1308,6 +1308,14 @@ int intel_engine_stop_cs(struct
>>> intel_engine_cs *engine)
>>> return -ENODEV;
>>> ENGINE_TRACE(engine, "\n");
>>> + /*
>>> + * TODO: Occasionally trying to stop the cs times out, but does not
>>
>> What is the TODO part? To figure out why is sometimes does not work?
>>
>>> + * adversely affect functionality. The timeout is set as a config
>>> + * parameter that defaults to 100ms. Assuming that this timeout is
>>> + * sufficient for any pending MI_FORCEWAKEs to complete. Once root
>>> + * caused, the caller must check and handler the return from this
>>
>> s/handler/handle/
>>
>> TODO is to convert the function to return an error?
>
> TODO: Find out why occasionally stopping the CS times out. Seen
> especially with gem_eio tests.
>
> I will update the comment to be clear.
This timeout is in general or with this patch only?
>>
>>> + * function.
>>> + */
>>> if (__intel_engine_stop_cs(engine, 1000, stop_timeout(engine))) {
>>> ENGINE_TRACE(engine,
>>> "timed out on STOP_RING -> IDLE; HEAD:%04x,
>>> TAIL:%04x\n",
>>> @@ -1334,6 +1342,75 @@ void intel_engine_cancel_stop_cs(struct
>>> intel_engine_cs *engine)
>>> ENGINE_WRITE_FW(engine, RING_MI_MODE,
>>> _MASKED_BIT_DISABLE(STOP_RING));
>>> }
>>> +static u32 __cs_pending_mi_force_wakes(struct intel_engine_cs *engine)
>>> +{
>>> + static const i915_reg_t _reg[I915_NUM_ENGINES] = {
>>> + [RCS0] = MSG_IDLE_CS,
>>> + [BCS0] = MSG_IDLE_BCS,
>>> + [VCS0] = MSG_IDLE_VCS0,
>>> + [VCS1] = MSG_IDLE_VCS1,
>>> + [VCS2] = MSG_IDLE_VCS2,
>>> + [VCS3] = MSG_IDLE_VCS3,
>>> + [VCS4] = MSG_IDLE_VCS4,
>>> + [VCS5] = MSG_IDLE_VCS5,
>>> + [VCS6] = MSG_IDLE_VCS6,
>>> + [VCS7] = MSG_IDLE_VCS7,
>>> + [VECS0] = MSG_IDLE_VECS0,
>>> + [VECS1] = MSG_IDLE_VECS1,
>>> + [VECS2] = MSG_IDLE_VECS2,
>>> + [VECS3] = MSG_IDLE_VECS3,
>>> + [CCS0] = MSG_IDLE_CS,
>>> + [CCS1] = MSG_IDLE_CS,
>>> + [CCS2] = MSG_IDLE_CS,
>>> + [CCS3] = MSG_IDLE_CS,
>>> + };
>>> + u32 val;
>>> +
>>> + if (!_reg[engine->id].reg)
>>> + return 0;
>>> +
>>> + val = intel_uncore_read(engine->uncore, _reg[engine->id]);
>>> +
>>> + /* bits[29:25] & bits[13:9] >> shift */
>>> + return (val & (val >> 16) & MSG_IDLE_FW_MASK) >> MSG_IDLE_FW_SHIFT;
>>> +}
>>> +
>>> +static void __gpm_wait_for_fw_complete(struct intel_gt *gt, u32
>>> fw_mask)
>>> +{
>>> + int ret;
>>> +
>>> + /* Ensure GPM receives fw up/down after CS is stopped */
>>> + udelay(1);
>>
>> What's with the udealys in here when __intel_wait_for_register_fw
>> already does some waiting?
>
> Once idle, the WA instructs us to wait 1us around checking this status.
> The assumption here is that __intel_wait_for_register_fw could just exit
> as soon as the condition is met by HW.
Okay, that one sounds plausible. But what about the udelay before
__intel_wait_for_register_fw? What difference does it make between:
1)
udelay
loop:
read
break if idle
udelay
2)
loop:
read
break if idle
udelay
Is the read wihtout the udelay dangerous?
Also, why is this doing a 5ms atomic wait? Why not fast-slow to be more
CPU friendly? Does the workaround suggest a typical wait time?
Regards,
Tvrtko
>
> Thanks,
> Umesh
>
>>
>>> +
>>> + /* Wait for forcewake request to complete in GPM */
>>> + ret = __intel_wait_for_register_fw(gt->uncore,
>>> + GEN9_PWRGT_DOMAIN_STATUS,
>>> + fw_mask, fw_mask, 5000, 0, NULL);
>>> +
>>> + /* Ensure CS receives fw ack from GPM */
>>> + udelay(1);
>>> +
>>> + if (ret)
>>> + GT_TRACE(gt, "Failed to complete pending forcewake %d\n", ret);
>>> +}
>>> +
>>> +/*
>>> + * Wa_22011802037:gen12: In addition to stopping the cs, we need to
>>> wait for any
>>> + * pending MI_FORCE_WAKEUP requests that the CS has initiated to
>>> complete. The
>>> + * pending status is indicated by bits[13:9] (masked by bits[
>>> 29:25]) in the
>>
>> Extra space in square brackets.
>>
>>> + * MSG_IDLE register. There's one MSG_IDLE register per reset
>>> domain. Since we
>>> + * are concerned only with the gt reset here, we use a logical OR of
>>> pending
>>> + * forcewakeups from all reset domains and then wait for them to
>>> complete by
>>> + * querying PWRGT_DOMAIN_STATUS.
>>> + */
>>> +void intel_engine_wait_for_pending_mi_fw(struct intel_engine_cs
>>> *engine)
>>> +{
>>> + u32 fw_pending = __cs_pending_mi_force_wakes(engine);
>>> +
>>> + if (fw_pending)
>>> + __gpm_wait_for_fw_complete(engine->gt, fw_pending);
>>> +}
>>> +
>>> static u32
>>> read_subslice_reg(const struct intel_engine_cs *engine,
>>> int slice, int subslice, i915_reg_t reg)
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>> index 86f7a9ac1c39..e139dc1e44eb 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>> @@ -2958,6 +2958,13 @@ static void execlists_reset_prepare(struct
>>> intel_engine_cs *engine)
>>> ring_set_paused(engine, 1);
>>> intel_engine_stop_cs(engine);
>>> + /*
>>> + * Wa_22011802037:gen11/gen12: In addition to stopping the cs,
>>> we need
>>> + * to wait for any pending mi force wakeups
>>> + */
>>> + if (GRAPHICS_VER(engine->i915) == 11 ||
>>> GRAPHICS_VER(engine->i915) == 12)
>>> + intel_engine_wait_for_pending_mi_fw(engine);
>>> +
>>> engine->execlists.reset_ccid = active_ccid(engine);
>>> }
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>> b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>> index 5423bfd301ad..75884e0a552e 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>> +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>> @@ -323,6 +323,13 @@ static void reset_prepare(struct intel_engine_cs
>>> *engine)
>>> ENGINE_TRACE(engine, "\n");
>>> intel_engine_stop_cs(engine);
>>> + /*
>>> + * Wa_22011802037:gen11/gen12: In addition to stopping the cs,
>>> we need
>>> + * to wait for any pending mi force wakeups
>>> + */
>>> + if (GRAPHICS_VER(engine->i915) == 11 ||
>>> GRAPHICS_VER(engine->i915) == 12)
>>
>> IS_GRAPHICS_VER
>>
>>> + intel_engine_wait_for_pending_mi_fw(engine);
>>> +
>>> if (!stop_ring(engine)) {
>>> /* G45 ring initialization often fails to reset head to zero */
>>> ENGINE_TRACE(engine,
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>> index 2c4ad4a65089..f69a9464585e 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>> @@ -310,8 +310,8 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
>>> if (IS_DG2(gt->i915))
>>> flags |= GUC_WA_DUAL_QUEUE;
>>> - /* Wa_22011802037: graphics version 12 */
>>> - if (GRAPHICS_VER(gt->i915) == 12)
>>> + /* Wa_22011802037: graphics version 11/12 */
>>> + if (GRAPHICS_VER(gt->i915) == 11 || GRAPHICS_VER(gt->i915) == 12)
>>
>> Ditto.
>>
>>> flags |= GUC_WA_PRE_PARSER;
>>> /* Wa_16011777198:dg2 */
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>> index 75291e9846c5..a3fe832eff0d 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>> @@ -1527,87 +1527,18 @@ static void guc_reset_state(struct
>>> intel_context *ce, u32 head, bool scrub)
>>> lrc_update_regs(ce, engine, head);
>>> }
>>> -static u32 __cs_pending_mi_force_wakes(struct intel_engine_cs *engine)
>>> -{
>>> - static const i915_reg_t _reg[I915_NUM_ENGINES] = {
>>> - [RCS0] = MSG_IDLE_CS,
>>> - [BCS0] = MSG_IDLE_BCS,
>>> - [VCS0] = MSG_IDLE_VCS0,
>>> - [VCS1] = MSG_IDLE_VCS1,
>>> - [VCS2] = MSG_IDLE_VCS2,
>>> - [VCS3] = MSG_IDLE_VCS3,
>>> - [VCS4] = MSG_IDLE_VCS4,
>>> - [VCS5] = MSG_IDLE_VCS5,
>>> - [VCS6] = MSG_IDLE_VCS6,
>>> - [VCS7] = MSG_IDLE_VCS7,
>>> - [VECS0] = MSG_IDLE_VECS0,
>>> - [VECS1] = MSG_IDLE_VECS1,
>>> - [VECS2] = MSG_IDLE_VECS2,
>>> - [VECS3] = MSG_IDLE_VECS3,
>>> - [CCS0] = MSG_IDLE_CS,
>>> - [CCS1] = MSG_IDLE_CS,
>>> - [CCS2] = MSG_IDLE_CS,
>>> - [CCS3] = MSG_IDLE_CS,
>>> - };
>>> - u32 val;
>>> -
>>> - if (!_reg[engine->id].reg)
>>> - return 0;
>>> -
>>> - val = intel_uncore_read(engine->uncore, _reg[engine->id]);
>>> -
>>> - /* bits[29:25] & bits[13:9] >> shift */
>>> - return (val & (val >> 16) & MSG_IDLE_FW_MASK) >> MSG_IDLE_FW_SHIFT;
>>> -}
>>> -
>>> -static void __gpm_wait_for_fw_complete(struct intel_gt *gt, u32
>>> fw_mask)
>>> -{
>>> - int ret;
>>> -
>>> - /* Ensure GPM receives fw up/down after CS is stopped */
>>> - udelay(1);
>>> -
>>> - /* Wait for forcewake request to complete in GPM */
>>> - ret = __intel_wait_for_register_fw(gt->uncore,
>>> - GEN9_PWRGT_DOMAIN_STATUS,
>>> - fw_mask, fw_mask, 5000, 0, NULL);
>>> -
>>> - /* Ensure CS receives fw ack from GPM */
>>> - udelay(1);
>>> -
>>> - if (ret)
>>> - GT_TRACE(gt, "Failed to complete pending forcewake %d\n", ret);
>>> -}
>>> -
>>> -/*
>>> - * Wa_22011802037:gen12: In addition to stopping the cs, we need to
>>> wait for any
>>> - * pending MI_FORCE_WAKEUP requests that the CS has initiated to
>>> complete. The
>>> - * pending status is indicated by bits[13:9] (masked by bits[
>>> 29:25]) in the
>>> - * MSG_IDLE register. There's one MSG_IDLE register per reset
>>> domain. Since we
>>> - * are concerned only with the gt reset here, we use a logical OR of
>>> pending
>>> - * forcewakeups from all reset domains and then wait for them to
>>> complete by
>>> - * querying PWRGT_DOMAIN_STATUS.
>>> - */
>>> static void guc_engine_reset_prepare(struct intel_engine_cs *engine)
>>> {
>>> - u32 fw_pending;
>>> -
>>> - if (GRAPHICS_VER(engine->i915) != 12)
>>> + if (GRAPHICS_VER(engine->i915) != 11 &&
>>> GRAPHICS_VER(engine->i915) != 12)
>>
>> !IS_GRAPHICS_VER
>>
>>> return;
>>> - /*
>>> - * Wa_22011802037
>>> - * TODO: Occasionally trying to stop the cs times out, but does not
>>> - * adversely affect functionality. The timeout is set as a config
>>> - * parameter that defaults to 100ms. Assuming that this timeout is
>>> - * sufficient for any pending MI_FORCEWAKEs to complete, ignore the
>>> - * timeout returned here until it is root caused.
>>> - */
>>> intel_engine_stop_cs(engine);
>>> - fw_pending = __cs_pending_mi_force_wakes(engine);
>>> - if (fw_pending)
>>> - __gpm_wait_for_fw_complete(engine->gt, fw_pending);
>>> + /*
>>> + * Wa_22011802037:gen11/gen12: In addition to stopping the cs,
>>> we need
>>> + * to wait for any pending mi force wakeups
>>> + */
>>> + intel_engine_wait_for_pending_mi_fw(engine);
>>> }
>>> static void guc_reset_nop(struct intel_engine_cs *engine)
>>
>> Regards,
>>
>> Tvrtko
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
2022-05-04 8:10 ` Tvrtko Ursulin
@ 2022-05-04 17:35 ` Umesh Nerlige Ramappa
2022-05-04 18:09 ` Tvrtko Ursulin
0 siblings, 1 reply; 11+ messages in thread
From: Umesh Nerlige Ramappa @ 2022-05-04 17:35 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: intel-gfx
On Wed, May 04, 2022 at 09:10:42AM +0100, Tvrtko Ursulin wrote:
>
>On 03/05/2022 20:49, Umesh Nerlige Ramappa wrote:
>>On Tue, May 03, 2022 at 09:42:52AM +0100, Tvrtko Ursulin wrote:
>>>
>>>On 02/05/2022 23:18, Umesh Nerlige Ramappa wrote:
>>>>Current implementation of Wa_22011802037 is limited to the GuC backend
>>>>and gen12. Add support for execlist backend and gen11 as well.
>>>
>>>Is the implication f6aa0d713c88 ("drm/i915: Add Wa_22011802037
>>>force cs halt") does not work on Tigerlake? Fixes: tag probably
>>>required in that case since I have sold that fix as a, well, fix.
>>
>>After the fix was made, the WA has evolved and added some more steps
>>for handling pending MI_FORCE_WAKEs. This patch is the additional
>>set of steps needed for the WA. As you mentioned offline, I should
>>correct the commit message to indicate that the WA does exist for
>>execlists, but needs additional steps. Will add Fixes: tag.
>
>Ok, that would be good then since it does sound they need to be tied
>together (as in cherry picked for fixes).
>
>Will it be followed up with preempt-to-idle implementation to avoid
>the, as I understand it, potential for activity on one CCS engine
>defeating the WA on another by timing out the wait for idle?
fwiu, for the case where we want to limit the reset to a single engine,
the preempt-to-idle implementation may be required -
https://patchwork.freedesktop.org/series/101432/. If preempt-to-idle
fails, the hangcheck should kick in and then do a gt-reset. If that
happens, then the WA flow in the patch should be applied.
>
>>>>Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>>>>---
>>>> drivers/gpu/drm/i915/gt/intel_engine.h | 2 +
>>>> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 81 ++++++++++++++++++-
>>>> .../drm/i915/gt/intel_execlists_submission.c | 7 ++
>>>> .../gpu/drm/i915/gt/intel_ring_submission.c | 7 ++
>>>> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 +-
>>>> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 81 ++-----------------
>>>> 6 files changed, 103 insertions(+), 79 deletions(-)
>>>>
>>>>diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
>>>>b/drivers/gpu/drm/i915/gt/intel_engine.h
>>>>index 1431f1e9dbee..04e435bce79b 100644
>>>>--- a/drivers/gpu/drm/i915/gt/intel_engine.h
>>>>+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
>>>>@@ -201,6 +201,8 @@ int intel_ring_submission_setup(struct
>>>>intel_engine_cs *engine);
>>>> int intel_engine_stop_cs(struct intel_engine_cs *engine);
>>>> void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
>>>>+void intel_engine_wait_for_pending_mi_fw(struct intel_engine_cs
>>>>*engine);
>>>>+
>>>> void intel_engine_set_hwsp_writemask(struct intel_engine_cs
>>>>*engine, u32 mask);
>>>> u64 intel_engine_get_active_head(const struct intel_engine_cs *engine);
>>>>diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>>>b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>>>index 14c6ddbbfde8..0bda665a407c 100644
>>>>--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>>>+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>>>@@ -1282,10 +1282,10 @@ static int __intel_engine_stop_cs(struct
>>>>intel_engine_cs *engine,
>>>> intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
>>>> /*
>>>>- * Wa_22011802037 : gen12, Prior to doing a reset, ensure CS is
>>>>+ * Wa_22011802037 : gen11, gen12, Prior to doing a reset,
>>>>ensure CS is
>>>> * stopped, set ring stop bit and prefetch disable bit to halt CS
>>>> */
>>>>- if (GRAPHICS_VER(engine->i915) == 12)
>>>>+ if (GRAPHICS_VER(engine->i915) == 11 ||
>>>>GRAPHICS_VER(engine->i915) == 12)
>>>
>>>IS_GRAPHICS_VER(11, 12)
>>>
>>>> intel_uncore_write_fw(uncore,
>>>>RING_MODE_GEN7(engine->mmio_base),
>>>> _MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));
>>>>@@ -1308,6 +1308,14 @@ int intel_engine_stop_cs(struct
>>>>intel_engine_cs *engine)
>>>> return -ENODEV;
>>>> ENGINE_TRACE(engine, "\n");
>>>>+ /*
>>>>+ * TODO: Occasionally trying to stop the cs times out, but does not
>>>
>>>What is the TODO part? To figure out why is sometimes does not work?
>>>
>>>>+ * adversely affect functionality. The timeout is set as a config
>>>>+ * parameter that defaults to 100ms. Assuming that this timeout is
>>>>+ * sufficient for any pending MI_FORCEWAKEs to complete. Once root
>>>>+ * caused, the caller must check and handler the return from this
>>>
>>>s/handler/handle/
>>>
>>>TODO is to convert the function to return an error?
>>
>>TODO: Find out why occasionally stopping the CS times out. Seen
>>especially with gem_eio tests.
>>
>>I will update the comment to be clear.
>
>This timeout is in general or with this patch only?
In general. I only tried it on dg2, but I don't see any existing caller
checking the return value of intel_engine_stop_cs.
>
>>>
>>>>+ * function.
>>>>+ */
>>>> if (__intel_engine_stop_cs(engine, 1000, stop_timeout(engine))) {
>>>> ENGINE_TRACE(engine,
>>>> "timed out on STOP_RING -> IDLE; HEAD:%04x,
>>>>TAIL:%04x\n",
>>>>@@ -1334,6 +1342,75 @@ void intel_engine_cancel_stop_cs(struct
>>>>intel_engine_cs *engine)
>>>> ENGINE_WRITE_FW(engine, RING_MI_MODE,
>>>>_MASKED_BIT_DISABLE(STOP_RING));
>>>> }
>>>>+static u32 __cs_pending_mi_force_wakes(struct intel_engine_cs *engine)
>>>>+{
>>>>+ static const i915_reg_t _reg[I915_NUM_ENGINES] = {
>>>>+ [RCS0] = MSG_IDLE_CS,
>>>>+ [BCS0] = MSG_IDLE_BCS,
>>>>+ [VCS0] = MSG_IDLE_VCS0,
>>>>+ [VCS1] = MSG_IDLE_VCS1,
>>>>+ [VCS2] = MSG_IDLE_VCS2,
>>>>+ [VCS3] = MSG_IDLE_VCS3,
>>>>+ [VCS4] = MSG_IDLE_VCS4,
>>>>+ [VCS5] = MSG_IDLE_VCS5,
>>>>+ [VCS6] = MSG_IDLE_VCS6,
>>>>+ [VCS7] = MSG_IDLE_VCS7,
>>>>+ [VECS0] = MSG_IDLE_VECS0,
>>>>+ [VECS1] = MSG_IDLE_VECS1,
>>>>+ [VECS2] = MSG_IDLE_VECS2,
>>>>+ [VECS3] = MSG_IDLE_VECS3,
>>>>+ [CCS0] = MSG_IDLE_CS,
>>>>+ [CCS1] = MSG_IDLE_CS,
>>>>+ [CCS2] = MSG_IDLE_CS,
>>>>+ [CCS3] = MSG_IDLE_CS,
>>>>+ };
>>>>+ u32 val;
>>>>+
>>>>+ if (!_reg[engine->id].reg)
>>>>+ return 0;
>>>>+
>>>>+ val = intel_uncore_read(engine->uncore, _reg[engine->id]);
>>>>+
>>>>+ /* bits[29:25] & bits[13:9] >> shift */
>>>>+ return (val & (val >> 16) & MSG_IDLE_FW_MASK) >> MSG_IDLE_FW_SHIFT;
>>>>+}
>>>>+
>>>>+static void __gpm_wait_for_fw_complete(struct intel_gt *gt, u32
>>>>fw_mask)
>>>>+{
>>>>+ int ret;
>>>>+
>>>>+ /* Ensure GPM receives fw up/down after CS is stopped */
>>>>+ udelay(1);
>>>
>>>What's with the udealys in here when __intel_wait_for_register_fw
>>>already does some waiting?
>>
>>Once idle, the WA instructs us to wait 1us around checking this
>>status. The assumption here is that __intel_wait_for_register_fw
>>could just exit as soon as the condition is met by HW.
>
>Okay, that one sounds plausible. But what about the udelay before
>__intel_wait_for_register_fw? What difference does it make between:
The previous operation was stop_cs and we still need to wait 1 us after
that. Although that wait is only specified for this WA. That's the
udelay before __intel_wait_for_register_fw.
>
>1)
>
>udelay
>loop:
> read
> break if idle
> udelay
>
>2)
>
>loop:
> read
> break if idle
> udelay
>
>Is the read wihtout the udelay dangerous?
I wouldn't think so. It's more of translating the WA from HW as is into
code. A loop should work too, I guess.
Thanks,
Umesh
>
>Also, why is this doing a 5ms atomic wait? Why not fast-slow to be
>more CPU friendly? Does the workaround suggest a typical wait time?
No wait time suggested in the WA. It's just a large enough value. I can
change it to fast = 500, slow = 5000.
Thanks,
Umesh
>
>Regards,
>
>Tvrtko
>
>>
>>Thanks,
>>Umesh
>>
>>>
>>>>+
>>>>+ /* Wait for forcewake request to complete in GPM */
>>>>+ ret = __intel_wait_for_register_fw(gt->uncore,
>>>>+ GEN9_PWRGT_DOMAIN_STATUS,
>>>>+ fw_mask, fw_mask, 5000, 0, NULL);
>>>>+
>>>>+ /* Ensure CS receives fw ack from GPM */
>>>>+ udelay(1);
>>>>+
>>>>+ if (ret)
>>>>+ GT_TRACE(gt, "Failed to complete pending forcewake %d\n", ret);
>>>>+}
>>>>+
>>>>+/*
>>>>+ * Wa_22011802037:gen12: In addition to stopping the cs, we
>>>>need to wait for any
>>>>+ * pending MI_FORCE_WAKEUP requests that the CS has initiated
>>>>to complete. The
>>>>+ * pending status is indicated by bits[13:9] (masked by bits[
>>>>29:25]) in the
>>>
>>>Extra space in square brackets.
>>>
>>>>+ * MSG_IDLE register. There's one MSG_IDLE register per reset
>>>>domain. Since we
>>>>+ * are concerned only with the gt reset here, we use a logical
>>>>OR of pending
>>>>+ * forcewakeups from all reset domains and then wait for them
>>>>to complete by
>>>>+ * querying PWRGT_DOMAIN_STATUS.
>>>>+ */
>>>>+void intel_engine_wait_for_pending_mi_fw(struct intel_engine_cs
>>>>*engine)
>>>>+{
>>>>+ u32 fw_pending = __cs_pending_mi_force_wakes(engine);
>>>>+
>>>>+ if (fw_pending)
>>>>+ __gpm_wait_for_fw_complete(engine->gt, fw_pending);
>>>>+}
>>>>+
>>>> static u32
>>>> read_subslice_reg(const struct intel_engine_cs *engine,
>>>> int slice, int subslice, i915_reg_t reg)
>>>>diff --git
>>>>a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>>>b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>>>index 86f7a9ac1c39..e139dc1e44eb 100644
>>>>--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>>>+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>>>@@ -2958,6 +2958,13 @@ static void
>>>>execlists_reset_prepare(struct intel_engine_cs *engine)
>>>> ring_set_paused(engine, 1);
>>>> intel_engine_stop_cs(engine);
>>>>+ /*
>>>>+ * Wa_22011802037:gen11/gen12: In addition to stopping the
>>>>cs, we need
>>>>+ * to wait for any pending mi force wakeups
>>>>+ */
>>>>+ if (GRAPHICS_VER(engine->i915) == 11 ||
>>>>GRAPHICS_VER(engine->i915) == 12)
>>>>+ intel_engine_wait_for_pending_mi_fw(engine);
>>>>+
>>>> engine->execlists.reset_ccid = active_ccid(engine);
>>>> }
>>>>diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>>>b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>>>index 5423bfd301ad..75884e0a552e 100644
>>>>--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>>>+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>>>@@ -323,6 +323,13 @@ static void reset_prepare(struct
>>>>intel_engine_cs *engine)
>>>> ENGINE_TRACE(engine, "\n");
>>>> intel_engine_stop_cs(engine);
>>>>+ /*
>>>>+ * Wa_22011802037:gen11/gen12: In addition to stopping the
>>>>cs, we need
>>>>+ * to wait for any pending mi force wakeups
>>>>+ */
>>>>+ if (GRAPHICS_VER(engine->i915) == 11 ||
>>>>GRAPHICS_VER(engine->i915) == 12)
>>>
>>>IS_GRAPHICS_VER
>>>
>>>>+ intel_engine_wait_for_pending_mi_fw(engine);
>>>>+
>>>> if (!stop_ring(engine)) {
>>>> /* G45 ring initialization often fails to reset head to zero */
>>>> ENGINE_TRACE(engine,
>>>>diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>>>b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>>>index 2c4ad4a65089..f69a9464585e 100644
>>>>--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>>>+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>>>@@ -310,8 +310,8 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
>>>> if (IS_DG2(gt->i915))
>>>> flags |= GUC_WA_DUAL_QUEUE;
>>>>- /* Wa_22011802037: graphics version 12 */
>>>>- if (GRAPHICS_VER(gt->i915) == 12)
>>>>+ /* Wa_22011802037: graphics version 11/12 */
>>>>+ if (GRAPHICS_VER(gt->i915) == 11 || GRAPHICS_VER(gt->i915) == 12)
>>>
>>>Ditto.
>>>
>>>> flags |= GUC_WA_PRE_PARSER;
>>>> /* Wa_16011777198:dg2 */
>>>>diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>index 75291e9846c5..a3fe832eff0d 100644
>>>>--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>@@ -1527,87 +1527,18 @@ static void guc_reset_state(struct
>>>>intel_context *ce, u32 head, bool scrub)
>>>> lrc_update_regs(ce, engine, head);
>>>> }
>>>>-static u32 __cs_pending_mi_force_wakes(struct intel_engine_cs *engine)
>>>>-{
>>>>- static const i915_reg_t _reg[I915_NUM_ENGINES] = {
>>>>- [RCS0] = MSG_IDLE_CS,
>>>>- [BCS0] = MSG_IDLE_BCS,
>>>>- [VCS0] = MSG_IDLE_VCS0,
>>>>- [VCS1] = MSG_IDLE_VCS1,
>>>>- [VCS2] = MSG_IDLE_VCS2,
>>>>- [VCS3] = MSG_IDLE_VCS3,
>>>>- [VCS4] = MSG_IDLE_VCS4,
>>>>- [VCS5] = MSG_IDLE_VCS5,
>>>>- [VCS6] = MSG_IDLE_VCS6,
>>>>- [VCS7] = MSG_IDLE_VCS7,
>>>>- [VECS0] = MSG_IDLE_VECS0,
>>>>- [VECS1] = MSG_IDLE_VECS1,
>>>>- [VECS2] = MSG_IDLE_VECS2,
>>>>- [VECS3] = MSG_IDLE_VECS3,
>>>>- [CCS0] = MSG_IDLE_CS,
>>>>- [CCS1] = MSG_IDLE_CS,
>>>>- [CCS2] = MSG_IDLE_CS,
>>>>- [CCS3] = MSG_IDLE_CS,
>>>>- };
>>>>- u32 val;
>>>>-
>>>>- if (!_reg[engine->id].reg)
>>>>- return 0;
>>>>-
>>>>- val = intel_uncore_read(engine->uncore, _reg[engine->id]);
>>>>-
>>>>- /* bits[29:25] & bits[13:9] >> shift */
>>>>- return (val & (val >> 16) & MSG_IDLE_FW_MASK) >> MSG_IDLE_FW_SHIFT;
>>>>-}
>>>>-
>>>>-static void __gpm_wait_for_fw_complete(struct intel_gt *gt, u32
>>>>fw_mask)
>>>>-{
>>>>- int ret;
>>>>-
>>>>- /* Ensure GPM receives fw up/down after CS is stopped */
>>>>- udelay(1);
>>>>-
>>>>- /* Wait for forcewake request to complete in GPM */
>>>>- ret = __intel_wait_for_register_fw(gt->uncore,
>>>>- GEN9_PWRGT_DOMAIN_STATUS,
>>>>- fw_mask, fw_mask, 5000, 0, NULL);
>>>>-
>>>>- /* Ensure CS receives fw ack from GPM */
>>>>- udelay(1);
>>>>-
>>>>- if (ret)
>>>>- GT_TRACE(gt, "Failed to complete pending forcewake %d\n", ret);
>>>>-}
>>>>-
>>>>-/*
>>>>- * Wa_22011802037:gen12: In addition to stopping the cs, we
>>>>need to wait for any
>>>>- * pending MI_FORCE_WAKEUP requests that the CS has initiated
>>>>to complete. The
>>>>- * pending status is indicated by bits[13:9] (masked by bits[
>>>>29:25]) in the
>>>>- * MSG_IDLE register. There's one MSG_IDLE register per reset
>>>>domain. Since we
>>>>- * are concerned only with the gt reset here, we use a logical
>>>>OR of pending
>>>>- * forcewakeups from all reset domains and then wait for them
>>>>to complete by
>>>>- * querying PWRGT_DOMAIN_STATUS.
>>>>- */
>>>> static void guc_engine_reset_prepare(struct intel_engine_cs *engine)
>>>> {
>>>>- u32 fw_pending;
>>>>-
>>>>- if (GRAPHICS_VER(engine->i915) != 12)
>>>>+ if (GRAPHICS_VER(engine->i915) != 11 &&
>>>>GRAPHICS_VER(engine->i915) != 12)
>>>
>>>!IS_GRAPHICS_VER
>>>
>>>> return;
>>>>- /*
>>>>- * Wa_22011802037
>>>>- * TODO: Occasionally trying to stop the cs times out, but does not
>>>>- * adversely affect functionality. The timeout is set as a config
>>>>- * parameter that defaults to 100ms. Assuming that this timeout is
>>>>- * sufficient for any pending MI_FORCEWAKEs to complete, ignore the
>>>>- * timeout returned here until it is root caused.
>>>>- */
>>>> intel_engine_stop_cs(engine);
>>>>- fw_pending = __cs_pending_mi_force_wakes(engine);
>>>>- if (fw_pending)
>>>>- __gpm_wait_for_fw_complete(engine->gt, fw_pending);
>>>>+ /*
>>>>+ * Wa_22011802037:gen11/gen12: In addition to stopping the
>>>>cs, we need
>>>>+ * to wait for any pending mi force wakeups
>>>>+ */
>>>>+ intel_engine_wait_for_pending_mi_fw(engine);
>>>> }
>>>> static void guc_reset_nop(struct intel_engine_cs *engine)
>>>
>>>Regards,
>>>
>>>Tvrtko
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
2022-05-04 17:35 ` Umesh Nerlige Ramappa
@ 2022-05-04 18:09 ` Tvrtko Ursulin
2022-05-04 18:45 ` Umesh Nerlige Ramappa
2022-05-06 17:13 ` Umesh Nerlige Ramappa
0 siblings, 2 replies; 11+ messages in thread
From: Tvrtko Ursulin @ 2022-05-04 18:09 UTC (permalink / raw)
To: Umesh Nerlige Ramappa; +Cc: intel-gfx
On 04/05/2022 18:35, Umesh Nerlige Ramappa wrote:
> On Wed, May 04, 2022 at 09:10:42AM +0100, Tvrtko Ursulin wrote:
>>
>> On 03/05/2022 20:49, Umesh Nerlige Ramappa wrote:
>>> On Tue, May 03, 2022 at 09:42:52AM +0100, Tvrtko Ursulin wrote:
>>>>
>>>> On 02/05/2022 23:18, Umesh Nerlige Ramappa wrote:
>>>>> Current implementation of Wa_22011802037 is limited to the GuC backend
>>>>> and gen12. Add support for execlist backend and gen11 as well.
>>>>
>>>> Is the implication f6aa0d713c88 ("drm/i915: Add Wa_22011802037 force
>>>> cs halt") does not work on Tigerlake? Fixes: tag probably required
>>>> in that case since I have sold that fix as a, well, fix.
>>>
>>> After the fix was made, the WA has evolved and added some more steps
>>> for handling pending MI_FORCE_WAKEs. This patch is the additional set
>>> of steps needed for the WA. As you mentioned offline, I should
>>> correct the commit message to indicate that the WA does exist for
>>> execlists, but needs additional steps. Will add Fixes: tag.
>>
>> Ok, that would be good then since it does sound they need to be tied
>> together (as in cherry picked for fixes).
>>
>> Will it be followed up with preempt-to-idle implementation to avoid
>> the, as I understand it, potential for activity on one CCS engine
>> defeating the WA on another by timing out the wait for idle?
>
> fwiu, for the case where we want to limit the reset to a single engine,
> the preempt-to-idle implementation may be required -
> https://patchwork.freedesktop.org/series/101432/. If preempt-to-idle
> fails, the hangcheck should kick in and then do a gt-reset. If that
> happens, then the WA flow in the patch should be applied.
Okay I read that as yes. That is fine by me since this patch alone is
better than without it.
>>>>> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>>>>> ---
>>>>> drivers/gpu/drm/i915/gt/intel_engine.h | 2 +
>>>>> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 81
>>>>> ++++++++++++++++++-
>>>>> .../drm/i915/gt/intel_execlists_submission.c | 7 ++
>>>>> .../gpu/drm/i915/gt/intel_ring_submission.c | 7 ++
>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 +-
>>>>> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 81
>>>>> ++-----------------
>>>>> 6 files changed, 103 insertions(+), 79 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
>>>>> b/drivers/gpu/drm/i915/gt/intel_engine.h
>>>>> index 1431f1e9dbee..04e435bce79b 100644
>>>>> --- a/drivers/gpu/drm/i915/gt/intel_engine.h
>>>>> +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
>>>>> @@ -201,6 +201,8 @@ int intel_ring_submission_setup(struct
>>>>> intel_engine_cs *engine);
>>>>> int intel_engine_stop_cs(struct intel_engine_cs *engine);
>>>>> void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
>>>>> +void intel_engine_wait_for_pending_mi_fw(struct intel_engine_cs
>>>>> *engine);
>>>>> +
>>>>> void intel_engine_set_hwsp_writemask(struct intel_engine_cs
>>>>> *engine, u32 mask);
>>>>> u64 intel_engine_get_active_head(const struct intel_engine_cs
>>>>> *engine);
>>>>> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>>>> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>>>> index 14c6ddbbfde8..0bda665a407c 100644
>>>>> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>>>> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>>>> @@ -1282,10 +1282,10 @@ static int __intel_engine_stop_cs(struct
>>>>> intel_engine_cs *engine,
>>>>> intel_uncore_write_fw(uncore, mode,
>>>>> _MASKED_BIT_ENABLE(STOP_RING));
>>>>> /*
>>>>> - * Wa_22011802037 : gen12, Prior to doing a reset, ensure CS is
>>>>> + * Wa_22011802037 : gen11, gen12, Prior to doing a reset,
>>>>> ensure CS is
>>>>> * stopped, set ring stop bit and prefetch disable bit to halt CS
>>>>> */
>>>>> - if (GRAPHICS_VER(engine->i915) == 12)
>>>>> + if (GRAPHICS_VER(engine->i915) == 11 ||
>>>>> GRAPHICS_VER(engine->i915) == 12)
>>>>
>>>> IS_GRAPHICS_VER(11, 12)
>>>>
>>>>> intel_uncore_write_fw(uncore,
>>>>> RING_MODE_GEN7(engine->mmio_base),
>>>>>
>>>>> _MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));
>>>>> @@ -1308,6 +1308,14 @@ int intel_engine_stop_cs(struct
>>>>> intel_engine_cs *engine)
>>>>> return -ENODEV;
>>>>> ENGINE_TRACE(engine, "\n");
>>>>> + /*
>>>>> + * TODO: Occasionally trying to stop the cs times out, but
>>>>> does not
>>>>
>>>> What is the TODO part? To figure out why is sometimes does not work?
>>>>
>>>>> + * adversely affect functionality. The timeout is set as a config
>>>>> + * parameter that defaults to 100ms. Assuming that this
>>>>> timeout is
>>>>> + * sufficient for any pending MI_FORCEWAKEs to complete. Once
>>>>> root
>>>>> + * caused, the caller must check and handler the return from this
>>>>
>>>> s/handler/handle/
>>>>
>>>> TODO is to convert the function to return an error?
>>>
>>> TODO: Find out why occasionally stopping the CS times out. Seen
>>> especially with gem_eio tests.
>>>
>>> I will update the comment to be clear.
>>
>> This timeout is in general or with this patch only?
>
> In general. I only tried it on dg2, but I don't see any existing caller
> checking the return value of intel_engine_stop_cs.
Okay, then perhaps adding a comment in this patch added some confusion.
Fine either way.
>>>>
>>>>> + * function.
>>>>> + */
>>>>> if (__intel_engine_stop_cs(engine, 1000, stop_timeout(engine))) {
>>>>> ENGINE_TRACE(engine,
>>>>> "timed out on STOP_RING -> IDLE; HEAD:%04x,
>>>>> TAIL:%04x\n",
>>>>> @@ -1334,6 +1342,75 @@ void intel_engine_cancel_stop_cs(struct
>>>>> intel_engine_cs *engine)
>>>>> ENGINE_WRITE_FW(engine, RING_MI_MODE,
>>>>> _MASKED_BIT_DISABLE(STOP_RING));
>>>>> }
>>>>> +static u32 __cs_pending_mi_force_wakes(struct intel_engine_cs
>>>>> *engine)
>>>>> +{
>>>>> + static const i915_reg_t _reg[I915_NUM_ENGINES] = {
>>>>> + [RCS0] = MSG_IDLE_CS,
>>>>> + [BCS0] = MSG_IDLE_BCS,
>>>>> + [VCS0] = MSG_IDLE_VCS0,
>>>>> + [VCS1] = MSG_IDLE_VCS1,
>>>>> + [VCS2] = MSG_IDLE_VCS2,
>>>>> + [VCS3] = MSG_IDLE_VCS3,
>>>>> + [VCS4] = MSG_IDLE_VCS4,
>>>>> + [VCS5] = MSG_IDLE_VCS5,
>>>>> + [VCS6] = MSG_IDLE_VCS6,
>>>>> + [VCS7] = MSG_IDLE_VCS7,
>>>>> + [VECS0] = MSG_IDLE_VECS0,
>>>>> + [VECS1] = MSG_IDLE_VECS1,
>>>>> + [VECS2] = MSG_IDLE_VECS2,
>>>>> + [VECS3] = MSG_IDLE_VECS3,
>>>>> + [CCS0] = MSG_IDLE_CS,
>>>>> + [CCS1] = MSG_IDLE_CS,
>>>>> + [CCS2] = MSG_IDLE_CS,
>>>>> + [CCS3] = MSG_IDLE_CS,
>>>>> + };
>>>>> + u32 val;
>>>>> +
>>>>> + if (!_reg[engine->id].reg)
>>>>> + return 0;
>>>>> +
>>>>> + val = intel_uncore_read(engine->uncore, _reg[engine->id]);
>>>>> +
>>>>> + /* bits[29:25] & bits[13:9] >> shift */
>>>>> + return (val & (val >> 16) & MSG_IDLE_FW_MASK) >>
>>>>> MSG_IDLE_FW_SHIFT;
>>>>> +}
>>>>> +
>>>>> +static void __gpm_wait_for_fw_complete(struct intel_gt *gt, u32
>>>>> fw_mask)
>>>>> +{
>>>>> + int ret;
>>>>> +
>>>>> + /* Ensure GPM receives fw up/down after CS is stopped */
>>>>> + udelay(1);
>>>>
>>>> What's with the udealys in here when __intel_wait_for_register_fw
>>>> already does some waiting?
>>>
>>> Once idle, the WA instructs us to wait 1us around checking this
>>> status. The assumption here is that __intel_wait_for_register_fw
>>> could just exit as soon as the condition is met by HW.
>>
>> Okay, that one sounds plausible. But what about the udelay before
>> __intel_wait_for_register_fw? What difference does it make between:
>
> The previous operation was stop_cs and we still need to wait 1 us after
> that. Although that wait is only specified for this WA. That's the
> udelay before __intel_wait_for_register_fw.
Right, what does the WA say - wait 1us before reading the register?
Perhaps they expect the reaction time of 1us.
>>
>> 1)
>>
>> udelay
>> loop:
>> read
>> break if idle
>> udelay
>>
>> 2)
>>
>> loop:
>> read
>> break if idle
>> udelay
>>
>> Is the read wihtout the udelay dangerous?
>
> I wouldn't think so. It's more of translating the WA from HW as is into
> code. A loop should work too, I guess.
Oh I did not mean to convert it to a loop, I was illustrating how I
don't see how the udelay before the loop (loop being inside
__intel_wait_for_register_fw) makes sense. I just expanded the sequence
to make it clearer what I mean. :)
>> Also, why is this doing a 5ms atomic wait? Why not fast-slow to be
>> more CPU friendly? Does the workaround suggest a typical wait time?
>
> No wait time suggested in the WA. It's just a large enough value. I can
> change it to fast = 500, slow = 5000.
No idea without any numbers or guidance. Only asking question when
suspicious things noticed.
Add some logging to see how long it takes in practice and then set
triple timeout to triple that? And double check my thinking that
sleeping wait is okay in this context please before doing it. :)
Regards,
Tvrtko
>>
>> Regards,
>>
>> Tvrtko
>>
>>>
>>> Thanks,
>>> Umesh
>>>
>>>>
>>>>> +
>>>>> + /* Wait for forcewake request to complete in GPM */
>>>>> + ret = __intel_wait_for_register_fw(gt->uncore,
>>>>> + GEN9_PWRGT_DOMAIN_STATUS,
>>>>> + fw_mask, fw_mask, 5000, 0, NULL);
>>>>> +
>>>>> + /* Ensure CS receives fw ack from GPM */
>>>>> + udelay(1);
>>>>> +
>>>>> + if (ret)
>>>>> + GT_TRACE(gt, "Failed to complete pending forcewake %d\n",
>>>>> ret);
>>>>> +}
>>>>> +
>>>>> +/*
>>>>> + * Wa_22011802037:gen12: In addition to stopping the cs, we need
>>>>> to wait for any
>>>>> + * pending MI_FORCE_WAKEUP requests that the CS has initiated to
>>>>> complete. The
>>>>> + * pending status is indicated by bits[13:9] (masked by bits[
>>>>> 29:25]) in the
>>>>
>>>> Extra space in square brackets.
>>>>
>>>>> + * MSG_IDLE register. There's one MSG_IDLE register per reset
>>>>> domain. Since we
>>>>> + * are concerned only with the gt reset here, we use a logical OR
>>>>> of pending
>>>>> + * forcewakeups from all reset domains and then wait for them to
>>>>> complete by
>>>>> + * querying PWRGT_DOMAIN_STATUS.
>>>>> + */
>>>>> +void intel_engine_wait_for_pending_mi_fw(struct intel_engine_cs
>>>>> *engine)
>>>>> +{
>>>>> + u32 fw_pending = __cs_pending_mi_force_wakes(engine);
>>>>> +
>>>>> + if (fw_pending)
>>>>> + __gpm_wait_for_fw_complete(engine->gt, fw_pending);
>>>>> +}
>>>>> +
>>>>> static u32
>>>>> read_subslice_reg(const struct intel_engine_cs *engine,
>>>>> int slice, int subslice, i915_reg_t reg)
>>>>> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>>>> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>>>> index 86f7a9ac1c39..e139dc1e44eb 100644
>>>>> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>>>> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>>>> @@ -2958,6 +2958,13 @@ static void execlists_reset_prepare(struct
>>>>> intel_engine_cs *engine)
>>>>> ring_set_paused(engine, 1);
>>>>> intel_engine_stop_cs(engine);
>>>>> + /*
>>>>> + * Wa_22011802037:gen11/gen12: In addition to stopping the cs,
>>>>> we need
>>>>> + * to wait for any pending mi force wakeups
>>>>> + */
>>>>> + if (GRAPHICS_VER(engine->i915) == 11 ||
>>>>> GRAPHICS_VER(engine->i915) == 12)
>>>>> + intel_engine_wait_for_pending_mi_fw(engine);
>>>>> +
>>>>> engine->execlists.reset_ccid = active_ccid(engine);
>>>>> }
>>>>> diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>>>> b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>>>> index 5423bfd301ad..75884e0a552e 100644
>>>>> --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>>>> +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>>>> @@ -323,6 +323,13 @@ static void reset_prepare(struct
>>>>> intel_engine_cs *engine)
>>>>> ENGINE_TRACE(engine, "\n");
>>>>> intel_engine_stop_cs(engine);
>>>>> + /*
>>>>> + * Wa_22011802037:gen11/gen12: In addition to stopping the cs,
>>>>> we need
>>>>> + * to wait for any pending mi force wakeups
>>>>> + */
>>>>> + if (GRAPHICS_VER(engine->i915) == 11 ||
>>>>> GRAPHICS_VER(engine->i915) == 12)
>>>>
>>>> IS_GRAPHICS_VER
>>>>
>>>>> + intel_engine_wait_for_pending_mi_fw(engine);
>>>>> +
>>>>> if (!stop_ring(engine)) {
>>>>> /* G45 ring initialization often fails to reset head to
>>>>> zero */
>>>>> ENGINE_TRACE(engine,
>>>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>>>> index 2c4ad4a65089..f69a9464585e 100644
>>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>>>> @@ -310,8 +310,8 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
>>>>> if (IS_DG2(gt->i915))
>>>>> flags |= GUC_WA_DUAL_QUEUE;
>>>>> - /* Wa_22011802037: graphics version 12 */
>>>>> - if (GRAPHICS_VER(gt->i915) == 12)
>>>>> + /* Wa_22011802037: graphics version 11/12 */
>>>>> + if (GRAPHICS_VER(gt->i915) == 11 || GRAPHICS_VER(gt->i915) == 12)
>>>>
>>>> Ditto.
>>>>
>>>>> flags |= GUC_WA_PRE_PARSER;
>>>>> /* Wa_16011777198:dg2 */
>>>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>> index 75291e9846c5..a3fe832eff0d 100644
>>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>> @@ -1527,87 +1527,18 @@ static void guc_reset_state(struct
>>>>> intel_context *ce, u32 head, bool scrub)
>>>>> lrc_update_regs(ce, engine, head);
>>>>> }
>>>>> -static u32 __cs_pending_mi_force_wakes(struct intel_engine_cs
>>>>> *engine)
>>>>> -{
>>>>> - static const i915_reg_t _reg[I915_NUM_ENGINES] = {
>>>>> - [RCS0] = MSG_IDLE_CS,
>>>>> - [BCS0] = MSG_IDLE_BCS,
>>>>> - [VCS0] = MSG_IDLE_VCS0,
>>>>> - [VCS1] = MSG_IDLE_VCS1,
>>>>> - [VCS2] = MSG_IDLE_VCS2,
>>>>> - [VCS3] = MSG_IDLE_VCS3,
>>>>> - [VCS4] = MSG_IDLE_VCS4,
>>>>> - [VCS5] = MSG_IDLE_VCS5,
>>>>> - [VCS6] = MSG_IDLE_VCS6,
>>>>> - [VCS7] = MSG_IDLE_VCS7,
>>>>> - [VECS0] = MSG_IDLE_VECS0,
>>>>> - [VECS1] = MSG_IDLE_VECS1,
>>>>> - [VECS2] = MSG_IDLE_VECS2,
>>>>> - [VECS3] = MSG_IDLE_VECS3,
>>>>> - [CCS0] = MSG_IDLE_CS,
>>>>> - [CCS1] = MSG_IDLE_CS,
>>>>> - [CCS2] = MSG_IDLE_CS,
>>>>> - [CCS3] = MSG_IDLE_CS,
>>>>> - };
>>>>> - u32 val;
>>>>> -
>>>>> - if (!_reg[engine->id].reg)
>>>>> - return 0;
>>>>> -
>>>>> - val = intel_uncore_read(engine->uncore, _reg[engine->id]);
>>>>> -
>>>>> - /* bits[29:25] & bits[13:9] >> shift */
>>>>> - return (val & (val >> 16) & MSG_IDLE_FW_MASK) >>
>>>>> MSG_IDLE_FW_SHIFT;
>>>>> -}
>>>>> -
>>>>> -static void __gpm_wait_for_fw_complete(struct intel_gt *gt, u32
>>>>> fw_mask)
>>>>> -{
>>>>> - int ret;
>>>>> -
>>>>> - /* Ensure GPM receives fw up/down after CS is stopped */
>>>>> - udelay(1);
>>>>> -
>>>>> - /* Wait for forcewake request to complete in GPM */
>>>>> - ret = __intel_wait_for_register_fw(gt->uncore,
>>>>> - GEN9_PWRGT_DOMAIN_STATUS,
>>>>> - fw_mask, fw_mask, 5000, 0, NULL);
>>>>> -
>>>>> - /* Ensure CS receives fw ack from GPM */
>>>>> - udelay(1);
>>>>> -
>>>>> - if (ret)
>>>>> - GT_TRACE(gt, "Failed to complete pending forcewake %d\n",
>>>>> ret);
>>>>> -}
>>>>> -
>>>>> -/*
>>>>> - * Wa_22011802037:gen12: In addition to stopping the cs, we need
>>>>> to wait for any
>>>>> - * pending MI_FORCE_WAKEUP requests that the CS has initiated to
>>>>> complete. The
>>>>> - * pending status is indicated by bits[13:9] (masked by bits[
>>>>> 29:25]) in the
>>>>> - * MSG_IDLE register. There's one MSG_IDLE register per reset
>>>>> domain. Since we
>>>>> - * are concerned only with the gt reset here, we use a logical OR
>>>>> of pending
>>>>> - * forcewakeups from all reset domains and then wait for them to
>>>>> complete by
>>>>> - * querying PWRGT_DOMAIN_STATUS.
>>>>> - */
>>>>> static void guc_engine_reset_prepare(struct intel_engine_cs *engine)
>>>>> {
>>>>> - u32 fw_pending;
>>>>> -
>>>>> - if (GRAPHICS_VER(engine->i915) != 12)
>>>>> + if (GRAPHICS_VER(engine->i915) != 11 &&
>>>>> GRAPHICS_VER(engine->i915) != 12)
>>>>
>>>> !IS_GRAPHICS_VER
>>>>
>>>>> return;
>>>>> - /*
>>>>> - * Wa_22011802037
>>>>> - * TODO: Occasionally trying to stop the cs times out, but
>>>>> does not
>>>>> - * adversely affect functionality. The timeout is set as a config
>>>>> - * parameter that defaults to 100ms. Assuming that this
>>>>> timeout is
>>>>> - * sufficient for any pending MI_FORCEWAKEs to complete,
>>>>> ignore the
>>>>> - * timeout returned here until it is root caused.
>>>>> - */
>>>>> intel_engine_stop_cs(engine);
>>>>> - fw_pending = __cs_pending_mi_force_wakes(engine);
>>>>> - if (fw_pending)
>>>>> - __gpm_wait_for_fw_complete(engine->gt, fw_pending);
>>>>> + /*
>>>>> + * Wa_22011802037:gen11/gen12: In addition to stopping the cs,
>>>>> we need
>>>>> + * to wait for any pending mi force wakeups
>>>>> + */
>>>>> + intel_engine_wait_for_pending_mi_fw(engine);
>>>>> }
>>>>> static void guc_reset_nop(struct intel_engine_cs *engine)
>>>>
>>>> Regards,
>>>>
>>>> Tvrtko
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
2022-05-04 18:09 ` Tvrtko Ursulin
@ 2022-05-04 18:45 ` Umesh Nerlige Ramappa
2022-05-06 17:13 ` Umesh Nerlige Ramappa
1 sibling, 0 replies; 11+ messages in thread
From: Umesh Nerlige Ramappa @ 2022-05-04 18:45 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: intel-gfx
On Wed, May 04, 2022 at 07:09:09PM +0100, Tvrtko Ursulin wrote:
>
>On 04/05/2022 18:35, Umesh Nerlige Ramappa wrote:
>>On Wed, May 04, 2022 at 09:10:42AM +0100, Tvrtko Ursulin wrote:
>>>
>>>On 03/05/2022 20:49, Umesh Nerlige Ramappa wrote:
>>>>On Tue, May 03, 2022 at 09:42:52AM +0100, Tvrtko Ursulin wrote:
>>>>>
>>>>>On 02/05/2022 23:18, Umesh Nerlige Ramappa wrote:
>>>>>>Current implementation of Wa_22011802037 is limited to the GuC backend
>>>>>>and gen12. Add support for execlist backend and gen11 as well.
>>>>>
>>>>>Is the implication f6aa0d713c88 ("drm/i915: Add Wa_22011802037
>>>>>force cs halt") does not work on Tigerlake? Fixes: tag
>>>>>probably required in that case since I have sold that fix as
>>>>>a, well, fix.
>>>>
>>>>After the fix was made, the WA has evolved and added some more
>>>>steps for handling pending MI_FORCE_WAKEs. This patch is the
>>>>additional set of steps needed for the WA. As you mentioned
>>>>offline, I should correct the commit message to indicate that
>>>>the WA does exist for execlists, but needs additional steps.
>>>>Will add Fixes: tag.
>>>
>>>Ok, that would be good then since it does sound they need to be
>>>tied together (as in cherry picked for fixes).
>>>
>>>Will it be followed up with preempt-to-idle implementation to
>>>avoid the, as I understand it, potential for activity on one CCS
>>>engine defeating the WA on another by timing out the wait for
>>>idle?
>>
>>fwiu, for the case where we want to limit the reset to a single
>>engine, the preempt-to-idle implementation may be required -
>>https://patchwork.freedesktop.org/series/101432/. If preempt-to-idle
>>fails, the hangcheck should kick in and then do a gt-reset. If that
>>happens, then the WA flow in the patch should be applied.
>
>Okay I read that as yes. That is fine by me since this patch alone is
>better than without it.
>
>>>>>>Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>>>>>>---
>>>>>> drivers/gpu/drm/i915/gt/intel_engine.h | 2 +
>>>>>> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 81
>>>>>>++++++++++++++++++-
>>>>>> .../drm/i915/gt/intel_execlists_submission.c | 7 ++
>>>>>> .../gpu/drm/i915/gt/intel_ring_submission.c | 7 ++
>>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 +-
>>>>>> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 81
>>>>>>++-----------------
>>>>>> 6 files changed, 103 insertions(+), 79 deletions(-)
>>>>>>
>>>>>>diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
>>>>>>b/drivers/gpu/drm/i915/gt/intel_engine.h
>>>>>>index 1431f1e9dbee..04e435bce79b 100644
>>>>>>--- a/drivers/gpu/drm/i915/gt/intel_engine.h
>>>>>>+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
>>>>>>@@ -201,6 +201,8 @@ int intel_ring_submission_setup(struct
>>>>>>intel_engine_cs *engine);
>>>>>> int intel_engine_stop_cs(struct intel_engine_cs *engine);
>>>>>> void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
>>>>>>+void intel_engine_wait_for_pending_mi_fw(struct
>>>>>>intel_engine_cs *engine);
>>>>>>+
>>>>>> void intel_engine_set_hwsp_writemask(struct intel_engine_cs
>>>>>>*engine, u32 mask);
>>>>>> u64 intel_engine_get_active_head(const struct
>>>>>>intel_engine_cs *engine);
>>>>>>diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>>>>>b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>>>>>index 14c6ddbbfde8..0bda665a407c 100644
>>>>>>--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>>>>>+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>>>>>>@@ -1282,10 +1282,10 @@ static int
>>>>>>__intel_engine_stop_cs(struct intel_engine_cs *engine,
>>>>>> intel_uncore_write_fw(uncore, mode,
>>>>>>_MASKED_BIT_ENABLE(STOP_RING));
>>>>>> /*
>>>>>>- * Wa_22011802037 : gen12, Prior to doing a reset, ensure CS is
>>>>>>+ * Wa_22011802037 : gen11, gen12, Prior to doing a
>>>>>>reset, ensure CS is
>>>>>> * stopped, set ring stop bit and prefetch disable bit to halt CS
>>>>>> */
>>>>>>- if (GRAPHICS_VER(engine->i915) == 12)
>>>>>>+ if (GRAPHICS_VER(engine->i915) == 11 ||
>>>>>>GRAPHICS_VER(engine->i915) == 12)
>>>>>
>>>>>IS_GRAPHICS_VER(11, 12)
>>>>>
>>>>>> intel_uncore_write_fw(uncore,
>>>>>>RING_MODE_GEN7(engine->mmio_base),
>>>>>>_MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));
>>>>>>@@ -1308,6 +1308,14 @@ int intel_engine_stop_cs(struct
>>>>>>intel_engine_cs *engine)
>>>>>> return -ENODEV;
>>>>>> ENGINE_TRACE(engine, "\n");
>>>>>>+ /*
>>>>>>+ * TODO: Occasionally trying to stop the cs times out,
>>>>>>but does not
>>>>>
>>>>>What is the TODO part? To figure out why is sometimes does not work?
>>>>>
>>>>>>+ * adversely affect functionality. The timeout is set as a config
>>>>>>+ * parameter that defaults to 100ms. Assuming that this
>>>>>>timeout is
>>>>>>+ * sufficient for any pending MI_FORCEWAKEs to
>>>>>>complete. Once root
>>>>>>+ * caused, the caller must check and handler the return from this
>>>>>
>>>>>s/handler/handle/
>>>>>
>>>>>TODO is to convert the function to return an error?
>>>>
>>>>TODO: Find out why occasionally stopping the CS times out. Seen
>>>>especially with gem_eio tests.
>>>>
>>>>I will update the comment to be clear.
>>>
>>>This timeout is in general or with this patch only?
>>
>>In general. I only tried it on dg2, but I don't see any existing
>>caller checking the return value of intel_engine_stop_cs.
>
>Okay, then perhaps adding a comment in this patch added some
>confusion. Fine either way.
>
>>>>>
>>>>>>+ * function.
>>>>>>+ */
>>>>>> if (__intel_engine_stop_cs(engine, 1000, stop_timeout(engine))) {
>>>>>> ENGINE_TRACE(engine,
>>>>>> "timed out on STOP_RING -> IDLE;
>>>>>>HEAD:%04x, TAIL:%04x\n",
>>>>>>@@ -1334,6 +1342,75 @@ void
>>>>>>intel_engine_cancel_stop_cs(struct intel_engine_cs *engine)
>>>>>> ENGINE_WRITE_FW(engine, RING_MI_MODE,
>>>>>>_MASKED_BIT_DISABLE(STOP_RING));
>>>>>> }
>>>>>>+static u32 __cs_pending_mi_force_wakes(struct
>>>>>>intel_engine_cs *engine)
>>>>>>+{
>>>>>>+ static const i915_reg_t _reg[I915_NUM_ENGINES] = {
>>>>>>+ [RCS0] = MSG_IDLE_CS,
>>>>>>+ [BCS0] = MSG_IDLE_BCS,
>>>>>>+ [VCS0] = MSG_IDLE_VCS0,
>>>>>>+ [VCS1] = MSG_IDLE_VCS1,
>>>>>>+ [VCS2] = MSG_IDLE_VCS2,
>>>>>>+ [VCS3] = MSG_IDLE_VCS3,
>>>>>>+ [VCS4] = MSG_IDLE_VCS4,
>>>>>>+ [VCS5] = MSG_IDLE_VCS5,
>>>>>>+ [VCS6] = MSG_IDLE_VCS6,
>>>>>>+ [VCS7] = MSG_IDLE_VCS7,
>>>>>>+ [VECS0] = MSG_IDLE_VECS0,
>>>>>>+ [VECS1] = MSG_IDLE_VECS1,
>>>>>>+ [VECS2] = MSG_IDLE_VECS2,
>>>>>>+ [VECS3] = MSG_IDLE_VECS3,
>>>>>>+ [CCS0] = MSG_IDLE_CS,
>>>>>>+ [CCS1] = MSG_IDLE_CS,
>>>>>>+ [CCS2] = MSG_IDLE_CS,
>>>>>>+ [CCS3] = MSG_IDLE_CS,
>>>>>>+ };
>>>>>>+ u32 val;
>>>>>>+
>>>>>>+ if (!_reg[engine->id].reg)
>>>>>>+ return 0;
>>>>>>+
>>>>>>+ val = intel_uncore_read(engine->uncore, _reg[engine->id]);
>>>>>>+
>>>>>>+ /* bits[29:25] & bits[13:9] >> shift */
>>>>>>+ return (val & (val >> 16) & MSG_IDLE_FW_MASK) >>
>>>>>>MSG_IDLE_FW_SHIFT;
>>>>>>+}
>>>>>>+
>>>>>>+static void __gpm_wait_for_fw_complete(struct intel_gt *gt,
>>>>>>u32 fw_mask)
>>>>>>+{
>>>>>>+ int ret;
>>>>>>+
>>>>>>+ /* Ensure GPM receives fw up/down after CS is stopped */
>>>>>>+ udelay(1);
>>>>>
>>>>>What's with the udealys in here when
>>>>>__intel_wait_for_register_fw already does some waiting?
>>>>
>>>>Once idle, the WA instructs us to wait 1us around checking this
>>>>status. The assumption here is that __intel_wait_for_register_fw
>>>>could just exit as soon as the condition is met by HW.
>>>
>>>Okay, that one sounds plausible. But what about the udelay before
>>>__intel_wait_for_register_fw? What difference does it make
>>>between:
>>
>>The previous operation was stop_cs and we still need to wait 1 us
>>after that. Although that wait is only specified for this WA. That's
>>the udelay before __intel_wait_for_register_fw.
>
>Right, what does the WA say - wait 1us before reading the register?
>Perhaps they expect the reaction time of 1us.
It says:
"Wait for 1us of time (Ensure GPM has received force wake up/down
request from CS after parsing stopped)"
>
>>>
>>>1)
>>>
>>>udelay
>>>loop:
>>> read
>>> break if idle
>>> udelay
>>>
>>>2)
>>>
>>>loop:
>>> read
>>> break if idle
>>> udelay
>>>
>>>Is the read wihtout the udelay dangerous?
>>
>>I wouldn't think so. It's more of translating the WA from HW as is
>>into code. A loop should work too, I guess.
>
>Oh I did not mean to convert it to a loop, I was illustrating how I
>don't see how the udelay before the loop (loop being inside
>__intel_wait_for_register_fw) makes sense. I just expanded the
>sequence to make it clearer what I mean. :)
>
>>>Also, why is this doing a 5ms atomic wait? Why not fast-slow to be
>>>more CPU friendly? Does the workaround suggest a typical wait
>>>time?
>>
>>No wait time suggested in the WA. It's just a large enough value. I
>>can change it to fast = 500, slow = 5000.
>
>No idea without any numbers or guidance. Only asking question when
>suspicious things noticed.
>
>Add some logging to see how long it takes in practice and then set
>triple timeout to triple that? And double check my thinking that
>sleeping wait is okay in this context please before doing it. :)
Will check it out.
Thanks,
Umesh
>
>Regards,
>
>Tvrtko
>
>>>
>>>Regards,
>>>
>>>Tvrtko
>>>
>>>>
>>>>Thanks,
>>>>Umesh
>>>>
>>>>>
>>>>>>+
>>>>>>+ /* Wait for forcewake request to complete in GPM */
>>>>>>+ ret = __intel_wait_for_register_fw(gt->uncore,
>>>>>>+ GEN9_PWRGT_DOMAIN_STATUS,
>>>>>>+ fw_mask, fw_mask, 5000, 0, NULL);
>>>>>>+
>>>>>>+ /* Ensure CS receives fw ack from GPM */
>>>>>>+ udelay(1);
>>>>>>+
>>>>>>+ if (ret)
>>>>>>+ GT_TRACE(gt, "Failed to complete pending forcewake
>>>>>>%d\n", ret);
>>>>>>+}
>>>>>>+
>>>>>>+/*
>>>>>>+ * Wa_22011802037:gen12: In addition to stopping the cs, we
>>>>>>need to wait for any
>>>>>>+ * pending MI_FORCE_WAKEUP requests that the CS has
>>>>>>initiated to complete. The
>>>>>>+ * pending status is indicated by bits[13:9] (masked by
>>>>>>bits[ 29:25]) in the
>>>>>
>>>>>Extra space in square brackets.
>>>>>
>>>>>>+ * MSG_IDLE register. There's one MSG_IDLE register per
>>>>>>reset domain. Since we
>>>>>>+ * are concerned only with the gt reset here, we use a
>>>>>>logical OR of pending
>>>>>>+ * forcewakeups from all reset domains and then wait for
>>>>>>them to complete by
>>>>>>+ * querying PWRGT_DOMAIN_STATUS.
>>>>>>+ */
>>>>>>+void intel_engine_wait_for_pending_mi_fw(struct
>>>>>>intel_engine_cs *engine)
>>>>>>+{
>>>>>>+ u32 fw_pending = __cs_pending_mi_force_wakes(engine);
>>>>>>+
>>>>>>+ if (fw_pending)
>>>>>>+ __gpm_wait_for_fw_complete(engine->gt, fw_pending);
>>>>>>+}
>>>>>>+
>>>>>> static u32
>>>>>> read_subslice_reg(const struct intel_engine_cs *engine,
>>>>>> int slice, int subslice, i915_reg_t reg)
>>>>>>diff --git
>>>>>>a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>>>>>b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>>>>>index 86f7a9ac1c39..e139dc1e44eb 100644
>>>>>>--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>>>>>+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
>>>>>>@@ -2958,6 +2958,13 @@ static void
>>>>>>execlists_reset_prepare(struct intel_engine_cs *engine)
>>>>>> ring_set_paused(engine, 1);
>>>>>> intel_engine_stop_cs(engine);
>>>>>>+ /*
>>>>>>+ * Wa_22011802037:gen11/gen12: In addition to stopping
>>>>>>the cs, we need
>>>>>>+ * to wait for any pending mi force wakeups
>>>>>>+ */
>>>>>>+ if (GRAPHICS_VER(engine->i915) == 11 ||
>>>>>>GRAPHICS_VER(engine->i915) == 12)
>>>>>>+ intel_engine_wait_for_pending_mi_fw(engine);
>>>>>>+
>>>>>> engine->execlists.reset_ccid = active_ccid(engine);
>>>>>> }
>>>>>>diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>>>>>b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>>>>>index 5423bfd301ad..75884e0a552e 100644
>>>>>>--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>>>>>+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
>>>>>>@@ -323,6 +323,13 @@ static void reset_prepare(struct
>>>>>>intel_engine_cs *engine)
>>>>>> ENGINE_TRACE(engine, "\n");
>>>>>> intel_engine_stop_cs(engine);
>>>>>>+ /*
>>>>>>+ * Wa_22011802037:gen11/gen12: In addition to stopping
>>>>>>the cs, we need
>>>>>>+ * to wait for any pending mi force wakeups
>>>>>>+ */
>>>>>>+ if (GRAPHICS_VER(engine->i915) == 11 ||
>>>>>>GRAPHICS_VER(engine->i915) == 12)
>>>>>
>>>>>IS_GRAPHICS_VER
>>>>>
>>>>>>+ intel_engine_wait_for_pending_mi_fw(engine);
>>>>>>+
>>>>>> if (!stop_ring(engine)) {
>>>>>> /* G45 ring initialization often fails to reset
>>>>>>head to zero */
>>>>>> ENGINE_TRACE(engine,
>>>>>>diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>>>>>b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>>>>>index 2c4ad4a65089..f69a9464585e 100644
>>>>>>--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>>>>>+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>>>>>@@ -310,8 +310,8 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
>>>>>> if (IS_DG2(gt->i915))
>>>>>> flags |= GUC_WA_DUAL_QUEUE;
>>>>>>- /* Wa_22011802037: graphics version 12 */
>>>>>>- if (GRAPHICS_VER(gt->i915) == 12)
>>>>>>+ /* Wa_22011802037: graphics version 11/12 */
>>>>>>+ if (GRAPHICS_VER(gt->i915) == 11 || GRAPHICS_VER(gt->i915) == 12)
>>>>>
>>>>>Ditto.
>>>>>
>>>>>> flags |= GUC_WA_PRE_PARSER;
>>>>>> /* Wa_16011777198:dg2 */
>>>>>>diff --git
>>>>>>a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>index 75291e9846c5..a3fe832eff0d 100644
>>>>>>--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>>>>>@@ -1527,87 +1527,18 @@ static void guc_reset_state(struct
>>>>>>intel_context *ce, u32 head, bool scrub)
>>>>>> lrc_update_regs(ce, engine, head);
>>>>>> }
>>>>>>-static u32 __cs_pending_mi_force_wakes(struct
>>>>>>intel_engine_cs *engine)
>>>>>>-{
>>>>>>- static const i915_reg_t _reg[I915_NUM_ENGINES] = {
>>>>>>- [RCS0] = MSG_IDLE_CS,
>>>>>>- [BCS0] = MSG_IDLE_BCS,
>>>>>>- [VCS0] = MSG_IDLE_VCS0,
>>>>>>- [VCS1] = MSG_IDLE_VCS1,
>>>>>>- [VCS2] = MSG_IDLE_VCS2,
>>>>>>- [VCS3] = MSG_IDLE_VCS3,
>>>>>>- [VCS4] = MSG_IDLE_VCS4,
>>>>>>- [VCS5] = MSG_IDLE_VCS5,
>>>>>>- [VCS6] = MSG_IDLE_VCS6,
>>>>>>- [VCS7] = MSG_IDLE_VCS7,
>>>>>>- [VECS0] = MSG_IDLE_VECS0,
>>>>>>- [VECS1] = MSG_IDLE_VECS1,
>>>>>>- [VECS2] = MSG_IDLE_VECS2,
>>>>>>- [VECS3] = MSG_IDLE_VECS3,
>>>>>>- [CCS0] = MSG_IDLE_CS,
>>>>>>- [CCS1] = MSG_IDLE_CS,
>>>>>>- [CCS2] = MSG_IDLE_CS,
>>>>>>- [CCS3] = MSG_IDLE_CS,
>>>>>>- };
>>>>>>- u32 val;
>>>>>>-
>>>>>>- if (!_reg[engine->id].reg)
>>>>>>- return 0;
>>>>>>-
>>>>>>- val = intel_uncore_read(engine->uncore, _reg[engine->id]);
>>>>>>-
>>>>>>- /* bits[29:25] & bits[13:9] >> shift */
>>>>>>- return (val & (val >> 16) & MSG_IDLE_FW_MASK) >>
>>>>>>MSG_IDLE_FW_SHIFT;
>>>>>>-}
>>>>>>-
>>>>>>-static void __gpm_wait_for_fw_complete(struct intel_gt *gt,
>>>>>>u32 fw_mask)
>>>>>>-{
>>>>>>- int ret;
>>>>>>-
>>>>>>- /* Ensure GPM receives fw up/down after CS is stopped */
>>>>>>- udelay(1);
>>>>>>-
>>>>>>- /* Wait for forcewake request to complete in GPM */
>>>>>>- ret = __intel_wait_for_register_fw(gt->uncore,
>>>>>>- GEN9_PWRGT_DOMAIN_STATUS,
>>>>>>- fw_mask, fw_mask, 5000, 0, NULL);
>>>>>>-
>>>>>>- /* Ensure CS receives fw ack from GPM */
>>>>>>- udelay(1);
>>>>>>-
>>>>>>- if (ret)
>>>>>>- GT_TRACE(gt, "Failed to complete pending forcewake
>>>>>>%d\n", ret);
>>>>>>-}
>>>>>>-
>>>>>>-/*
>>>>>>- * Wa_22011802037:gen12: In addition to stopping the cs, we
>>>>>>need to wait for any
>>>>>>- * pending MI_FORCE_WAKEUP requests that the CS has
>>>>>>initiated to complete. The
>>>>>>- * pending status is indicated by bits[13:9] (masked by
>>>>>>bits[ 29:25]) in the
>>>>>>- * MSG_IDLE register. There's one MSG_IDLE register per
>>>>>>reset domain. Since we
>>>>>>- * are concerned only with the gt reset here, we use a
>>>>>>logical OR of pending
>>>>>>- * forcewakeups from all reset domains and then wait for
>>>>>>them to complete by
>>>>>>- * querying PWRGT_DOMAIN_STATUS.
>>>>>>- */
>>>>>> static void guc_engine_reset_prepare(struct intel_engine_cs *engine)
>>>>>> {
>>>>>>- u32 fw_pending;
>>>>>>-
>>>>>>- if (GRAPHICS_VER(engine->i915) != 12)
>>>>>>+ if (GRAPHICS_VER(engine->i915) != 11 &&
>>>>>>GRAPHICS_VER(engine->i915) != 12)
>>>>>
>>>>>!IS_GRAPHICS_VER
>>>>>
>>>>>> return;
>>>>>>- /*
>>>>>>- * Wa_22011802037
>>>>>>- * TODO: Occasionally trying to stop the cs times out,
>>>>>>but does not
>>>>>>- * adversely affect functionality. The timeout is set as a config
>>>>>>- * parameter that defaults to 100ms. Assuming that this
>>>>>>timeout is
>>>>>>- * sufficient for any pending MI_FORCEWAKEs to
>>>>>>complete, ignore the
>>>>>>- * timeout returned here until it is root caused.
>>>>>>- */
>>>>>> intel_engine_stop_cs(engine);
>>>>>>- fw_pending = __cs_pending_mi_force_wakes(engine);
>>>>>>- if (fw_pending)
>>>>>>- __gpm_wait_for_fw_complete(engine->gt, fw_pending);
>>>>>>+ /*
>>>>>>+ * Wa_22011802037:gen11/gen12: In addition to stopping
>>>>>>the cs, we need
>>>>>>+ * to wait for any pending mi force wakeups
>>>>>>+ */
>>>>>>+ intel_engine_wait_for_pending_mi_fw(engine);
>>>>>> }
>>>>>> static void guc_reset_nop(struct intel_engine_cs *engine)
>>>>>
>>>>>Regards,
>>>>>
>>>>>Tvrtko
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
2022-05-04 18:09 ` Tvrtko Ursulin
2022-05-04 18:45 ` Umesh Nerlige Ramappa
@ 2022-05-06 17:13 ` Umesh Nerlige Ramappa
2022-05-06 21:08 ` Umesh Nerlige Ramappa
1 sibling, 1 reply; 11+ messages in thread
From: Umesh Nerlige Ramappa @ 2022-05-06 17:13 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: intel-gfx
On Wed, May 04, 2022 at 07:09:09PM +0100, Tvrtko Ursulin wrote:
>
>On 04/05/2022 18:35, Umesh Nerlige Ramappa wrote:
>>On Wed, May 04, 2022 at 09:10:42AM +0100, Tvrtko Ursulin wrote:
>>>
>>>On 03/05/2022 20:49, Umesh Nerlige Ramappa wrote:
>>>>On Tue, May 03, 2022 at 09:42:52AM +0100, Tvrtko Ursulin wrote:
>>>>>
>>>>>On 02/05/2022 23:18, Umesh Nerlige Ramappa wrote:
>>>>>>Current implementation of Wa_22011802037 is limited to the GuC backend
>>>>>>and gen12. Add support for execlist backend and gen11 as well.
>>>>>
>>>>>Is the implication f6aa0d713c88 ("drm/i915: Add Wa_22011802037
>>>>>force cs halt") does not work on Tigerlake? Fixes: tag
>>>>>probably required in that case since I have sold that fix as
>>>>>a, well, fix.
>>>>
>>>>After the fix was made, the WA has evolved and added some more
>>>>steps for handling pending MI_FORCE_WAKEs. This patch is the
>>>>additional set of steps needed for the WA. As you mentioned
>>>>offline, I should correct the commit message to indicate that
>>>>the WA does exist for execlists, but needs additional steps.
>>>>Will add Fixes: tag.
>>>
>>>Ok, that would be good then since it does sound they need to be
>>>tied together (as in cherry picked for fixes).
>>>
>>>Will it be followed up with preempt-to-idle implementation to
>>>avoid the, as I understand it, potential for activity on one CCS
>>>engine defeating the WA on another by timing out the wait for
>>>idle?
>>
>>fwiu, for the case where we want to limit the reset to a single
>>engine, the preempt-to-idle implementation may be required -
>>https://patchwork.freedesktop.org/series/101432/. If preempt-to-idle
>>fails, the hangcheck should kick in and then do a gt-reset. If that
>>happens, then the WA flow in the patch should be applied.
>
>Okay I read that as yes. That is fine by me since this patch alone is
>better than without it.
>
I have a general doubt for engines that do NOT share a reset domain,
specifically for execlist backend.
What is the expectation/behavior with the hangcheck initiated reset. It
says resetting chip for the engine that it decides is hung. In that path
it calls gt_reset which loops through engines (reset_prepare, rewind,
etc.). Are all running contexts victimized? OR is there an attempt to
preempt-to-idle contexts on other (innocent) engines and then resubmit
them if successfully preempted?
Thanks,
Umesh
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
2022-05-06 17:13 ` Umesh Nerlige Ramappa
@ 2022-05-06 21:08 ` Umesh Nerlige Ramappa
0 siblings, 0 replies; 11+ messages in thread
From: Umesh Nerlige Ramappa @ 2022-05-06 21:08 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: intel-gfx
On Fri, May 06, 2022 at 10:13:28AM -0700, Umesh Nerlige Ramappa wrote:
>On Wed, May 04, 2022 at 07:09:09PM +0100, Tvrtko Ursulin wrote:
>>
>>On 04/05/2022 18:35, Umesh Nerlige Ramappa wrote:
>>>On Wed, May 04, 2022 at 09:10:42AM +0100, Tvrtko Ursulin wrote:
>>>>
>>>>On 03/05/2022 20:49, Umesh Nerlige Ramappa wrote:
>>>>>On Tue, May 03, 2022 at 09:42:52AM +0100, Tvrtko Ursulin wrote:
>>>>>>
>>>>>>On 02/05/2022 23:18, Umesh Nerlige Ramappa wrote:
>>>>>>>Current implementation of Wa_22011802037 is limited to the GuC backend
>>>>>>>and gen12. Add support for execlist backend and gen11 as well.
>>>>>>
>>>>>>Is the implication f6aa0d713c88 ("drm/i915: Add
>>>>>>Wa_22011802037 force cs halt") does not work on Tigerlake?
>>>>>>Fixes: tag probably required in that case since I have sold
>>>>>>that fix as a, well, fix.
>>>>>
>>>>>After the fix was made, the WA has evolved and added some more
>>>>>steps for handling pending MI_FORCE_WAKEs. This patch is the
>>>>>additional set of steps needed for the WA. As you mentioned
>>>>>offline, I should correct the commit message to indicate that
>>>>>the WA does exist for execlists, but needs additional steps.
>>>>>Will add Fixes: tag.
>>>>
>>>>Ok, that would be good then since it does sound they need to be
>>>>tied together (as in cherry picked for fixes).
>>>>
>>>>Will it be followed up with preempt-to-idle implementation to
>>>>avoid the, as I understand it, potential for activity on one CCS
>>>>engine defeating the WA on another by timing out the wait for
>>>>idle?
>>>
>>>fwiu, for the case where we want to limit the reset to a single
>>>engine, the preempt-to-idle implementation may be required -
>>>https://patchwork.freedesktop.org/series/101432/. If
>>>preempt-to-idle fails, the hangcheck should kick in and then do a
>>>gt-reset. If that happens, then the WA flow in the patch should be
>>>applied.
>>
>>Okay I read that as yes. That is fine by me since this patch alone
>>is better than without it.
>>
>
>I have a general doubt for engines that do NOT share a reset domain,
>specifically for execlist backend.
>
>What is the expectation/behavior with the hangcheck initiated reset.
>It says resetting chip for the engine that it decides is hung. In that
>path it calls gt_reset which loops through engines (reset_prepare,
>rewind, etc.). Are all running contexts victimized? OR is there an
>attempt to preempt-to-idle contexts on other (innocent) engines and
>then resubmit them if successfully preempted?
nvm, I notice that all active contexts are marked as guilty, which is
what I was expecting. I think I ran into a test bug when trying to
understand this behavior, so wanted to ask. The test was running more
than one batch on the targeted engine and checking that both batches are
guilty, but that cannot happen, only the active contexts are marked
guilty.
Regards,
Umesh
>
>Thanks,
>Umesh
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-05-06 21:08 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-02 22:18 [Intel-gfx] [PATCH] drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend Umesh Nerlige Ramappa
2022-05-02 23:19 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for " Patchwork
2022-05-02 23:41 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-05-03 8:42 ` [Intel-gfx] [PATCH] " Tvrtko Ursulin
2022-05-03 19:49 ` Umesh Nerlige Ramappa
2022-05-04 8:10 ` Tvrtko Ursulin
2022-05-04 17:35 ` Umesh Nerlige Ramappa
2022-05-04 18:09 ` Tvrtko Ursulin
2022-05-04 18:45 ` Umesh Nerlige Ramappa
2022-05-06 17:13 ` Umesh Nerlige Ramappa
2022-05-06 21:08 ` Umesh Nerlige Ramappa
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.