public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Matt Roper <matthew.d.roper@intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 4/4] drm/i915/selftest: Use forcewake to sanity check engine wa lists
Date: Wed,  1 Feb 2023 14:28:31 -0800	[thread overview]
Message-ID: <20230201222831.608281-4-matthew.d.roper@intel.com> (raw)
In-Reply-To: <20230201222831.608281-1-matthew.d.roper@intel.com>

Although register information in the bspec includes a field that is
supposed to reflect a register's reset characteristics (i.e., whether a
register maintains its value through engine resets), it's been
discovered that this information is incorrect for some register ranges
(i.e., registers that are not affected by engine resets are tagged in a
way that indicates they would be).

We can sanity check workaround registers placed on the RCS/CCS engine
workaround lists (including those placed there via the
general_render_compute_wa_init() function) by comparing against the
forcewake table.  As far as we know, there's never a case where a
register that lives outside the RENDER powerwell will be reset by an
RCS/CCS engine reset.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
---
 .../gpu/drm/i915/gt/selftest_workarounds.c    | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
index 14a8b25b6204..1bc8febc5c1d 100644
--- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
@@ -1362,12 +1362,64 @@ live_engine_reset_workarounds(void *arg)
 	return ret;
 }
 
+/*
+ * The bspec's documentation for register reset behavior can be unreliable for
+ * some MMIO ranges.  But in general we do not expect registers outside the
+ * RENDER forcewake domain to be reset by RCS/CCS engine resets.  If we find
+ * workaround registers on an RCS or CCS engine's list, it likely indicates
+ * the register is misdocumented in the bspec and the workaround implementation
+ * should be moved to the GT workaround list instead.
+ */
+static int
+live_check_engine_workarounds_fw(void *arg)
+{
+	struct intel_gt *gt = arg;
+	struct intel_engine_cs *engine;
+	struct wa_lists *lists;
+	enum intel_engine_id id;
+	int ret = 0;
+
+	lists = kzalloc(sizeof(*lists), GFP_KERNEL);
+	if (!lists)
+		return -ENOMEM;
+
+	reference_lists_init(gt, lists);
+
+	for_each_engine(engine, gt, id) {
+		struct i915_wa_list *wal = &lists->engine[id].wa_list;
+		struct i915_wa *wa;
+		int i;
+
+		if (engine->class != RENDER_CLASS &&
+		    engine->class != COMPUTE_CLASS)
+			continue;
+
+		for (i = 0, wa = wal->list; i < wal->count; i++, wa++) {
+			enum forcewake_domains fw;
+
+			fw = intel_uncore_forcewake_for_reg(gt->uncore, wa->reg,
+							    FW_REG_READ | FW_REG_WRITE);
+			if ((fw & FORCEWAKE_RENDER) == 0) {
+				pr_err("%s: Register %#x not in RENDER forcewake domain!\n",
+				       engine->name, i915_mmio_reg_offset(wa->reg));
+				ret = -EINVAL;
+			}
+		}
+	}
+
+	reference_lists_fini(gt, lists);
+	kfree(lists);
+
+	return ret;
+}
+
 int intel_workarounds_live_selftests(struct drm_i915_private *i915)
 {
 	static const struct i915_subtest tests[] = {
 		SUBTEST(live_dirty_whitelist),
 		SUBTEST(live_reset_whitelist),
 		SUBTEST(live_isolated_whitelist),
+		SUBTEST(live_check_engine_workarounds_fw),
 		SUBTEST(live_gpu_reset_workarounds),
 		SUBTEST(live_engine_reset_workarounds),
 	};
-- 
2.39.1


  parent reply	other threads:[~2023-02-01 22:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-01 22:28 [Intel-gfx] [PATCH 1/4] drm/i915/pvc: Annotate two more workaround/tuning registers as MCR Matt Roper
2023-02-01 22:28 ` [Intel-gfx] [PATCH 2/4] drm/i915/gen11: Wa_1408615072/Wa_1407596294 should be on GT list Matt Roper
2023-02-07 19:10   ` Gustavo Sousa
2023-02-01 22:28 ` [Intel-gfx] [PATCH 3/4] drm/i915/xehp: LNCF/LBCF workarounds should be on the " Matt Roper
2023-02-07 20:33   ` Gustavo Sousa
2023-02-01 22:28 ` Matt Roper [this message]
2023-02-07 22:37   ` [Intel-gfx] [PATCH 4/4] drm/i915/selftest: Use forcewake to sanity check engine wa lists Gustavo Sousa
2023-02-08 12:51     ` Gustavo Sousa
2023-02-01 22:42 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915/pvc: Annotate two more workaround/tuning registers as MCR Patchwork
2023-02-01 23:17 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-02-02  0:29 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-02-07 18:33 ` [Intel-gfx] [PATCH 1/4] " Gustavo Sousa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230201222831.608281-4-matthew.d.roper@intel.com \
    --to=matthew.d.roper@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox