From: sashiko-bot@kernel.org
To: tilak.tirumalesh.tangudu@intel.com, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 1/4] drm/xe: Add has_sem64 bit to graphics/media IP descriptors
Date: Fri, 13 Nov 2026 16:20:19 +0000 [thread overview]
Message-ID: <sashiko-outbox-213185@kernel.org> (raw)
In-Reply-To: <20261113155734.4164230-2-tilak.tirumalesh.tangudu@intel.com>
Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] drm/xe: missing has_sem64 in graphics_xe3p_xpc disables sem64
on 35.11 and 35.03
- [Low] drm/xe: commit message mismatch with has_sem64 resolution in
xe_info_init()
--
commit aa9a045209e3c606e5aa5ffac66c1d9a9153a146
Author: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com>
drm/xe: Add has_sem64 bit to graphics/media IP descriptors
This commit adds a has_sem64 capability bit to the graphics and media IP
descriptors and populates gt->info.has_sem64 for Xe3p platforms.
> The bit indicates whether the GT's command streamer supports the
> MI_SEMAPHORE_WAIT_64 instruction. A platform's CS must not mix
> MI_SEMAPHORE_WAIT and MI_SEMAPHORE_WAIT_64 within a context or across
> context submissions, so both the primary and media GT must agree before
> either one enables sem64; resolve has_sem64 once in xe_info_init() and
> hand the single value to both GT allocators.
[Severity: Low]
Does the commit message match how has_sem64 is resolved?
alloc_primary_gt() and alloc_media_gt() each compute gt->info.has_sem64
independently from their IP descriptor and stepping, and xe_info_init()
afterwards clears both fields if either GT does not support it, rather
than resolving a single value in xe_info_init() and passing it to the GT
allocators.
> diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
> index 7fba5295c33e6..5a147a577a098 100644
> --- a/drivers/gpu/drm/xe/xe_pci.c
> +++ b/drivers/gpu/drm/xe/xe_pci.c
> @@ -127,6 +127,7 @@ static const struct xe_graphics_desc graphics_xe3p_lpg = {
> .multi_queue_engine_class_mask = BIT(XE_ENGINE_CLASS_COPY) | BIT(XE_ENGINE_CLASS_COMPUTE),
> .num_geometry_xecore_fuse_regs = 3,
> .num_compute_xecore_fuse_regs = 3,
> + .has_sem64 = 1,
> };
>
> static const struct xe_graphics_desc graphics_xe3p_xpc = {
> @@ -153,11 +154,20 @@ static const struct xe_media_desc media_xelpmp = {
> .hw_engine_mask =
> GENMASK(XE_HW_ENGINE_VCS7, XE_HW_ENGINE_VCS0) |
> GENMASK(XE_HW_ENGINE_VECS3, XE_HW_ENGINE_VECS0) |
> - BIT(XE_HW_ENGINE_GSCCS0)
> + BIT(XE_HW_ENGINE_GSCCS0),
> +};
> +
> +static const struct xe_media_desc media_xe3p_lpm = {
> + .hw_engine_mask =
> + GENMASK(XE_HW_ENGINE_VCS7, XE_HW_ENGINE_VCS0) |
> + GENMASK(XE_HW_ENGINE_VECS3, XE_HW_ENGINE_VECS0) |
> + BIT(XE_HW_ENGINE_GSCCS0),
> + .has_sem64 = 1,
> };
>
> static const struct xe_media_desc media_xe3p_hpm = {
> .has_uncorrectable_error_reporting = 1,
> + .has_sem64 = 1,
[Severity: Medium]
Should graphics_xe3p_xpc also set .has_sem64 = 1?
alloc_primary_gt() scopes the stepping B0 check to GRAPHICS_VERx100(xe) ==
3510 (graphics_xe3p_lpg), and media_xe3p_hpm (35.03) enables has_sem64.
Because graphics_xe3p_xpc (35.11) omits .has_sem64 = 1,
tile->primary_gt->info.has_sem64 is false on Xe3p_XPC platforms, and the
cross-GT check in xe_info_init() then clears
tile->media_gt->info.has_sem64 on the paired Xe3p_HPM media GT as well,
leaving sem64 disabled on both GTs.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261113155734.4164230-1-tilak.tirumalesh.tangudu@intel.com?part=1
next prev parent reply other threads:[~2026-11-13 16:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-13 15:57 [PATCH 0/4] drm/xe: Use MI_SEMAPHORE_WAIT_64 (Wa_16029281913) tilak.tirumalesh.tangudu
2026-11-13 15:57 ` [PATCH 1/4] drm/xe: Add has_sem64 bit to graphics/media IP descriptors tilak.tirumalesh.tangudu
2026-11-13 16:20 ` sashiko-bot [this message]
2026-11-13 15:57 ` [PATCH 2/4] drm/xe: Add MI_SEMAPHORE_WAIT_64 instruction definition tilak.tirumalesh.tangudu
2026-11-13 15:57 ` [PATCH 3/4] drm/xe: Use MI_SEMAPHORE_WAIT_64 for fake watchdog where supported tilak.tirumalesh.tangudu
2026-11-13 15:57 ` [PATCH 4/4] drm/xe: Use MI_SEMAPHORE_WAIT_64 in ULLS postamble " tilak.tirumalesh.tangudu
2026-11-13 16:34 ` ✗ CI.checkpatch: warning for drm/xe: Use MI_SEMAPHORE_WAIT_64 (Wa_16029281913) (rev3) Patchwork
2026-11-13 16:36 ` ✓ CI.KUnit: success " Patchwork
2026-11-13 17:09 ` ✓ Xe.CI.BAT: " 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=sashiko-outbox-213185@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tilak.tirumalesh.tangudu@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.