From: Navon John Lukose <navonjohnlukose@gmail.com>
To: "Tales A. Mendonça" <talesam@gmail.com>
Cc: intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
matthew.brost@intel.com, thomas.hellstrom@linux.intel.com,
rodrigo.vivi@intel.com, Matt Roper <matthew.d.roper@intel.com>
Subject: Re: [PATCH v1 2/4] drm/xe/mcr: Sanitize steering semaphore on GT resume
Date: Sun, 4 Oct 2026 01:15:48 +0530 [thread overview]
Message-ID: <20261003194548.14603-1-navonjohnlukose@gmail.com> (raw)
In-Reply-To: <20260722004654.744249-3-talesam@gmail.com>
On Tue, 21 Jul 2026 21:46:52 -0300, Tales A. Mendonça wrote:
> 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().
Tested on an ARL-H 7d51 (Lenovo Yoga Pro 7 14IAH10). Without this
patch, 7.2.8 hits the drm_WARN_ON_ONCE in mcr_lock() on the first
s2idle resume of every boot, lid open or closed.
With this patch on the same 7.2.8 build, without 1/4, the first
resume no longer warns. Later resumes can't show the _ONCE WARN
anyway, but a debug read of STEER_SEMAPHORE just before the release
found GT1's semaphore held on both resumes of that boot and GT0's
free, so the release is what fixes it. xe_gt_resume() already holds
XE_FORCEWAKE_ALL at that point, so the forcewake in 1/4 isn't needed
for this WARN.
Tested-by: Navon John Lukose <navonjohnlukose@gmail.com>
next prev parent reply other threads:[~2026-10-05 23:52 UTC|newest]
Thread overview: 22+ 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 ` [PATCH v1 2/4] drm/xe/mcr: Sanitize steering semaphore on GT resume Tales A. Mendonça
2026-07-22 13:57 ` sashiko-bot
2026-07-22 17:47 ` Tales A. Mendonça
2026-10-03 19:45 ` Navon John Lukose [this message]
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 21:10 ` Matthew Brost
2026-07-22 22:03 ` Matthew Brost
2026-07-22 23:28 ` Tales A. Mendonça
2026-07-23 0:26 ` Matthew Brost
2026-07-23 2:08 ` Tales A. Mendonça
2026-07-23 22:31 ` Tales A. Mendonça
2026-07-23 23:19 ` Matthew Brost
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=20261003194548.14603-1-navonjohnlukose@gmail.com \
--to=navonjohnlukose@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=matthew.d.roper@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=talesam@gmail.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.