From: Ville Syrjala <ville.syrjala@linux.intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: [PATCH 1/2] drm/i915/selftests: Nuke live_forcewake_domains selftest
Date: Mon, 23 Mar 2026 12:16:08 +0200 [thread overview]
Message-ID: <20260323101609.8391-2-ville.syrjala@linux.intel.com> (raw)
In-Reply-To: <20260323101609.8391-1-ville.syrjala@linux.intel.com>
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The live_forcewake_domains selftest doesn't really test anything
particularly sensible. It only runs on platforms that have RMbus
unclaimer error detection, but that only catches display registers
which the test doesn't even access.
I suppose if we really wanted to we might try to make the test
exercise the GT FIFO instead by writing GT registers as fast
as possible, and then checking GTFIFODBG to see if the FIFO has
overflowed. But dunno if there's much point in that. I think a
GT FIFO overflow might even be fatal to the machine.
So in its current for the test doesn't really make sense,
and it's in the way of moving all the RMbus noclaim stuff
to the display driver side. So let's just get rid of it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/selftests/intel_uncore.c | 62 -------------------
1 file changed, 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/intel_uncore.c b/drivers/gpu/drm/i915/selftests/intel_uncore.c
index 507bf42a1aaf..514d2200751b 100644
--- a/drivers/gpu/drm/i915/selftests/intel_uncore.c
+++ b/drivers/gpu/drm/i915/selftests/intel_uncore.c
@@ -272,67 +272,6 @@ static int live_forcewake_ops(void *arg)
return err;
}
-static int live_forcewake_domains(void *arg)
-{
-#define FW_RANGE 0x40000
- struct intel_gt *gt = arg;
- struct intel_uncore *uncore = gt->uncore;
- struct drm_i915_private *i915 = gt->i915;
- struct intel_display *display = i915->display;
- unsigned long *valid;
- u32 offset;
- int err;
-
- if (!HAS_FPGA_DBG_UNCLAIMED(display) &&
- !IS_VALLEYVIEW(i915) &&
- !IS_CHERRYVIEW(i915))
- return 0;
-
- /*
- * This test may lockup the machine or cause GPU hangs afterwards.
- */
- if (!IS_ENABLED(CONFIG_DRM_I915_SELFTEST_BROKEN))
- return 0;
-
- valid = bitmap_zalloc(FW_RANGE, GFP_KERNEL);
- if (!valid)
- return -ENOMEM;
-
- intel_uncore_forcewake_get(uncore, FORCEWAKE_ALL);
-
- check_for_unclaimed_mmio(uncore);
- for (offset = 0; offset < FW_RANGE; offset += 4) {
- i915_reg_t reg = { offset };
-
- intel_uncore_posting_read_fw(uncore, reg);
- if (!check_for_unclaimed_mmio(uncore))
- set_bit(offset, valid);
- }
-
- intel_uncore_forcewake_put(uncore, FORCEWAKE_ALL);
-
- err = 0;
- for_each_set_bit(offset, valid, FW_RANGE) {
- i915_reg_t reg = { offset };
-
- iosf_mbi_punit_acquire();
- intel_uncore_forcewake_reset(uncore);
- iosf_mbi_punit_release();
-
- check_for_unclaimed_mmio(uncore);
-
- intel_uncore_posting_read_fw(uncore, reg);
- if (check_for_unclaimed_mmio(uncore)) {
- pr_err("Unclaimed mmio read to register 0x%04x\n",
- offset);
- err = -EINVAL;
- }
- }
-
- bitmap_free(valid);
- return err;
-}
-
static int live_fw_table(void *arg)
{
struct intel_gt *gt = arg;
@@ -348,7 +287,6 @@ int intel_uncore_live_selftests(struct drm_i915_private *i915)
static const struct i915_subtest tests[] = {
SUBTEST(live_fw_table),
SUBTEST(live_forcewake_ops),
- SUBTEST(live_forcewake_domains),
};
return intel_gt_live_subtests(tests, to_gt(i915));
--
2.52.0
next prev parent reply other threads:[~2026-03-23 10:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-23 10:16 [PATCH 0/2] drm/i915/uncode: Decouple GT FIFO checks from unclaimed reg checks Ville Syrjala
2026-03-23 10:16 ` Ville Syrjala [this message]
2026-03-23 12:08 ` [PATCH 1/2] drm/i915/selftests: Nuke live_forcewake_domains selftest Jani Nikula
2026-03-23 10:16 ` [PATCH 2/2] drm/i915/uncore: Do GT FIFO checks in early sanitize and forcewake get Ville Syrjala
2026-03-25 15:54 ` Jani Nikula
2026-03-23 13:05 ` ✓ i915.CI.BAT: success for drm/i915/uncode: Decouple GT FIFO checks from unclaimed reg checks Patchwork
2026-03-23 17:49 ` ✓ i915.CI.Full: " Patchwork
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=20260323101609.8391-2-ville.syrjala@linux.intel.com \
--to=ville.syrjala@linux.intel.com \
--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