From: "Tales A. Mendonça" <talesam@gmail.com>
To: intel-xe@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org, matthew.brost@intel.com,
thomas.hellstrom@linux.intel.com, rodrigo.vivi@intel.com,
"Tales A. Mendonça" <talesam@gmail.com>
Subject: [PATCH v1 2/4] drm/xe/mcr: Sanitize steering semaphore on GT resume
Date: Tue, 21 Jul 2026 21:46:52 -0300 [thread overview]
Message-ID: <20260722004654.744249-3-talesam@gmail.com> (raw)
In-Reply-To: <20260722004654.744249-1-talesam@gmail.com>
The MCR steering semaphore can be left in a held state after a suspend
cycle. The first MCR access after resume then stalls until the
semaphore wait times out and logs:
Tile0: GT1: hardware MCR steering semaphore timed out
as observed on an Arrow Lake-P system resuming from s2idle. Recovery
currently only happens because mcr_unlock() releases the semaphore
unconditionally.
i915 addresses the same issue in intel_gt_resume_early() via
intel_gt_mcr_lock_sanitize(), noting that the hardware team confirmed
that forcibly releasing the semaphore is safe during driver
load/resume because no other agents acquire it at that time.
Port that to xe: release the steering semaphore at the start of
xe_gt_resume(), before the first MCR access performed by
do_gt_restart().
Signed-off-by: Tales A. Mendonça <talesam@gmail.com>
---
drivers/gpu/drm/xe/xe_gt.c | 7 +++++++
drivers/gpu/drm/xe/xe_gt_mcr.c | 22 ++++++++++++++++++++++
drivers/gpu/drm/xe/xe_gt_mcr.h | 1 +
3 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
index dfdacc0f6de..c61f3d9fc9a 100644
--- a/drivers/gpu/drm/xe/xe_gt.c
+++ b/drivers/gpu/drm/xe/xe_gt.c
@@ -1068,6 +1068,13 @@ int xe_gt_resume(struct xe_gt *gt)
return -ETIMEDOUT;
}
+ /*
+ * The MCR steering semaphore may be left held across a suspend
+ * cycle; release it before the first MCR access below so that
+ * mcr_lock() does not stall until the semaphore wait times out.
+ */
+ xe_gt_mcr_lock_sanitize(gt);
+
err = do_gt_restart(gt);
if (err)
return err;
diff --git a/drivers/gpu/drm/xe/xe_gt_mcr.c b/drivers/gpu/drm/xe/xe_gt_mcr.c
index e1e3c0688dc..3934d0de717 100644
--- a/drivers/gpu/drm/xe/xe_gt_mcr.c
+++ b/drivers/gpu/drm/xe/xe_gt_mcr.c
@@ -750,6 +750,28 @@ static void mcr_unlock(struct xe_gt *gt, unsigned int fw_ref) __releases(>->mc
}
}
+/**
+ * xe_gt_mcr_lock_sanitize - Release the hardware MCR steering semaphore
+ * @gt: GT structure
+ *
+ * The MCR steering semaphore can be left in a held state after a suspend
+ * cycle, in which case the first MCR access after resume stalls until the
+ * semaphore wait times out. Forcibly release the semaphore during driver
+ * load/resume; this is safe because no other agents acquire the semaphore
+ * during the load/resume process, mirroring i915's
+ * intel_gt_mcr_lock_sanitize().
+ */
+void xe_gt_mcr_lock_sanitize(struct xe_gt *gt)
+{
+ if (IS_SRIOV_VF(gt_to_xe(gt)))
+ return;
+
+ lockdep_assert_not_held(>->mcr_lock);
+
+ if (GRAPHICS_VERx100(gt_to_xe(gt)) >= 1270)
+ xe_mmio_write32(>->mmio, STEER_SEMAPHORE, 0x1);
+}
+
/*
* Access a register with specific MCR steering
*
diff --git a/drivers/gpu/drm/xe/xe_gt_mcr.h b/drivers/gpu/drm/xe/xe_gt_mcr.h
index 75374662f10..162f54075cf 100644
--- a/drivers/gpu/drm/xe/xe_gt_mcr.h
+++ b/drivers/gpu/drm/xe/xe_gt_mcr.h
@@ -16,6 +16,7 @@ void xe_gt_mcr_init_early(struct xe_gt *gt);
void xe_gt_mcr_init(struct xe_gt *gt);
void xe_gt_mcr_set_implicit_defaults(struct xe_gt *gt);
+void xe_gt_mcr_lock_sanitize(struct xe_gt *gt);
u32 xe_gt_mcr_unicast_read(struct xe_gt *gt, struct xe_reg_mcr mcr_reg,
int group, int instance);
--
2.55.0
next prev parent reply other threads:[~2026-07-22 13:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 0:46 [PATCH v1 0/4] drm/xe: MCR semaphore and TLB invalidation timeout fixes for ARL Tales A. Mendonça
2026-07-22 0:46 ` [PATCH v1 1/4] drm/xe/mcr: Keep GT forcewake during MCR steering Tales A. Mendonça
2026-07-22 14:02 ` sashiko-bot
2026-07-22 17:45 ` Tales A. Mendonça
2026-07-22 18:10 ` Matt Roper
2026-07-22 18:39 ` Tales A. Mendonça
2026-07-22 0:46 ` Tales A. Mendonça [this message]
2026-07-22 13:57 ` [PATCH v1 2/4] drm/xe/mcr: Sanitize steering semaphore on GT resume sashiko-bot
2026-07-22 17:47 ` Tales A. Mendonça
2026-07-22 0:46 ` [PATCH v1 3/4] drm/xe/guc/ct: Queue G2H worker before flushing it in timeout paths Tales A. Mendonça
2026-07-22 14:07 ` sashiko-bot
2026-07-22 17:48 ` Tales A. Mendonça
2026-07-22 0:46 ` [PATCH v1 4/4] drm/xe: Raise hw_tlb_timeout to cover observed GuC ack latency Tales A. Mendonça
2026-07-22 17:27 ` ✗ LGCI.VerificationFailed: failure for drm/xe: MCR semaphore and TLB invalidation timeout fixes for ARL 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=20260722004654.744249-3-talesam@gmail.com \
--to=talesam@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=thomas.hellstrom@linux.intel.com \
/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 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.