From: sashiko-bot@kernel.org
To: "Constantinos Chalkias" <cch@e-psn.eu>
Cc: intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/xe/hwmon: refresh Battlemage thermal telemetry under force-wake
Date: Mon, 12 Oct 2026 10:59:03 +0000 [thread overview]
Message-ID: <sashiko-outbox-168001@kernel.org> (raw)
In-Reply-To: <20261012104245.2108030-1-cch@e-psn.eu>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/xe: fan telemetry lacks Battlemage thermal force-wake workaround
--
commit a9faaf30cbf789280ad52add1cf188270e8ccad9
Author: Constantinos Chalkias <cch@e-psn.eu>
drm/xe/hwmon: refresh Battlemage thermal telemetry under force-wake
This commit works around stale thermal telemetry on Battlemage by
acquiring the GT force-wake domain and waiting 500-1000 us before
reading temperature registers.
> drm/xe/hwmon: refresh Battlemage thermal telemetry under force-wake
>
> On Battlemage, thermal telemetry can remain stale after the GT returns
> to RC6 following sustained workloads.
>
> On an Intel Arc Pro B70, package and VRAM temperature telemetry may stop
> refreshing after a long inference workload. Fan telemetry can also
> become invalid while the physical blower remains elevated.
[Severity: Medium]
The commit message states that fan telemetry can become invalid, but the
patch only applies the force-wake and delay workaround to temperature and
VRAM channels via xe_hwmon_temp_mmio_read().
Does xe_hwmon_fan_input_read() also need this workaround? Currently, it
continues to read REG_FAN_SPEED directly via xe_mmio_read32() without
acquiring force-wake or delaying:
drivers/gpu/drm/xe/xe_hwmon.c:xe_hwmon_fan_input_read() {
...
mutex_lock(&hwmon->hwmon_lock);
reg_val = xe_mmio_read32(mmio, xe_hwmon_get_reg(hwmon, REG_FAN_SPEED, channel));
time_now = get_jiffies_64();
...
}
Will fan telemetry still remain susceptible to staleness on Battlemage
without the workaround?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261012104245.2108030-1-cch@e-psn.eu?part=1
next prev parent reply other threads:[~2026-10-12 10:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 10:42 [PATCH] drm/xe/hwmon: refresh Battlemage thermal telemetry under force-wake Constantinos Chalkias
2026-10-12 10:59 ` sashiko-bot [this message]
2026-10-12 11:11 ` Constantinos Chalkias
2026-10-12 15:15 ` Simon Richter
2026-10-13 3:50 ` Simon.Richter
2026-10-12 18:50 ` ✗ LGCI.VerificationFailed: failure for " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2026-10-13 5:39 [PATCH] " Constantinos Chalkias
2026-10-13 10:25 ` Simon Richter
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-168001@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=cch@e-psn.eu \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.