[RFC PATCH 0/1] drm/xe/hwmon: wake render domain for BMG package temperature

[RFC PATCH 0/1] drm/xe/hwmon: wake render domain for BMG package temperature

[Yuta Higuchi]

Hello,

This RFC addresses a reproducible stale package-temperature value on one Intel
Arc Pro B70 (8086:e223). During GPU activity, temp2_input changes continuously.
After the workload exits, it changes for only a short lifecycle burst and then
remains fixed for more than 200 seconds during idle cooldown. Other telemetry,
including VRAM, mctrl, PCIe, fan, energy, and runtime state, continues to move.
An independent PID reading the same sysfs node sees the same result.

The symptom reproduces after cold boot, without OpenVINO, with a standard
clpeak workload, and on Linux 6.17, 7.0, 7.1.5, and 7.2-rc7 using the same
official BMG firmware. Holding runtime PM active alone did not restore idle
updates, and a controlled Xe reprobe did not restore continuous updates.

The tested firmware is byte-identical after decompression to official
linux-firmware main:

- DMC 2.6, content SHA-256
  76e3ec6ea3a53ce727e43b84f5ea14c55400a2d118dac356d4e12a3cfac06b4d;
- GuC 70.72.1, content SHA-256
  de81c75f46a127c33cd59f604d800e9ffc7ed3495967ba0d8767cd6985ab398b;
- HuC 8.2.10, content SHA-256
  747452aa8c4ed7760c68a80f3d913eafde9304d6f4db481e3f2aebb0a818bf15.

Source path and causal isolation
--------------------------------

For BMG, temp2_input reaches BMG_PACKAGE_TEMPERATURE (0x138434) through
xe_mmio_read32(). On the tested B70:

- stock forcewake_all kept package temperature updating;
- main-GT XE_FW_RENDER alone was sufficient in 3/3 independent persistent
  holder rounds;
- releasing the RENDER holder was followed immediately by renewed staleness in
  3/3 rounds;
- main-GT XE_FW_GT alone was negative in the single persistent-holder round
  tested;
- a transient RENDER acquisition produced the first fresh publication after
  1.17 to 2.172 ms; and
- after a 20 ms RENDER hold with no sysfs reads, the first package-temperature
  read was already fresh.

These observations support a wake/publication dependency rather than a
collector or sysfs-reader problem. They do not establish that register
0x138434 architecturally belongs to XE_FW_RENDER, nor whether PCODE, GuC, or
other firmware produces a shadow value.

Proposed RFC behavior
---------------------

For the BMG package-temperature channel only, acquire the main GT
XE_FW_RENDER domain, wait 3.0 to 3.5 ms, read the mapped package-temperature
register, and release the reference automatically. Forcewake acquisition
failure is returned as -ETIMEDOUT, following existing Xe forcewake-ACK timeout
precedent.

The 3.0 to 3.5 ms settling interval is empirical. The maximum fresh transition
latency observed in the transient tests was 2.172 ms. FORCEWAKE_ACK_RENDER is a
wake-domain acknowledgement; it has not been shown to be a temperature
producer-ready acknowledgement. The fixed delay is not presented as an
architectural contract.

Scope and known limitations
---------------------------

Runtime validation was performed on one Arc Pro B70 (8086:e223). The RFC is
scoped to Battlemage because the affected package-temperature path is
BMG-specific; guidance on applicability to other BMG devices and steppings is
welcome.

XE_FW_RENDER was single-domain sufficient among the directly compared states.
XE_FW_GT alone was tested once and was negative. Media, GSC, and other
individual forcewake domains were not tested after the RENDER-only positive was
established. This RFC does not claim that RENDER is the unique minimum among
every possible domain combination.

Validation
----------

Extensive runtime validation was performed with the equivalent diagnostic
implementation on Ubuntu 7.0:

- three independent 180-second cooldown rounds;
- 1, 5, 10, and 30 second read cadences;
- four concurrent readers (240/240 successful reads);
- 30 minutes of continuous operation;
- OpenVINO ruri-v3 and bge-m3 requests;
- suspend/resume; and
- controlled Xe unbind/rebind.

No GPU hang, reset, fault, or wedge occurred. Persistent RENDER forcewake had a
large power cost, whereas read-scoped references allowed GT idle residency to
advance. The displayed cur_freq remained 2800 MHz while act_freq was zero and
GT C6/idle residency progressed, so cur_freq was classified as telemetry state
rather than evidence of a physically busy GT.

The rebased current-tree candidate was additionally smoke-tested directly as
7.2.0-b70rfc2+, based on drm-tip 75140c4ee9ad. With the standard clpeak
workload, both a main reader and an independent PID observed package
temperature continue from 46 C down to 44 C during a 180-second cooldown.
act_freq was zero, GT entered C6, and idle residency advanced by 178.25
seconds. A separate bounded candidate-kernel test returned HTTP 200 for
OpenVINO ruri-v3 and bge-m3. No hang, reset, fault, wedge, or taint occurred.
This direct smoke does not include the 30-minute, suspend/resume, or reprobe
tests listed above; those were run only with the equivalent Ubuntu 7.0
diagnostic implementation.

On stock kernels, a separate operational workaround submits one warmed Intel
ICD work-item / one Xe job every 30 seconds and reads temp2_input 50 ms later.
That workaround refreshes snapshots but is not the proposed kernel behavior.

Related issues
--------------

Primary: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7805
Secondary: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4560

Questions for maintainers
-------------------------

1. Is 0x138434 a live sensor register, or a shadow value published by PCODE,
   GuC, or other firmware?
2. Is there a documented producer-ready indication after XE_FW_RENDER is
   acquired?
3. If not, what is the official minimum delay or refresh sequence for this
   register?

If an existing mechanism is available to trigger or wait for
package-temperature publication, I would prefer that over the empirical
settling delay used by this RFC.

Coding-assistant disclosure
---------------------------

AI coding assistants were used during this investigation and RFC preparation:
Claude Code for the initial investigation and independent review of the patch
against the current tree, OpenAI Codex for implementation, evidence collection
and test orchestration, and ChatGPT GPT-5.6 Sol Pro for investigation planning,
submission workflow design and review. The human submitter reviewed the
resulting code and evidence and takes responsibility for the submission.

Thanks,
Yuta Higuchi

Yuta Higuchi (1):
  drm/xe/hwmon: wake render domain for BMG package temperature

 drivers/gpu/drm/xe/xe_hwmon.c | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)


base-commit: 75140c4ee9ad250b2524ff5bfffd7f9fe4bb6012
-- 
2.43.0

[RFC PATCH 1/1] drm/xe/hwmon: wake render domain for BMG package temperature

[Yuta Higuchi]

On one Arc Pro B70 (8086:e223), the BMG package-temperature value
exposed as temp2_input updates continuously while the GPU is active. After
the final workload closes, it emits a short snapshot burst and then remains
stale for more than 200 seconds while VRAM, mctrl, PCIe, fan, energy, and
runtime state continue to change. An independent PID reading the same sysfs
node sees the same result, excluding the collector as the source of the
staleness.

The package-temperature read currently reaches BMG_PACKAGE_TEMPERATURE
(0x138434) through xe_mmio_read32() without an explicit forcewake
reference. Experiments on this Arc Pro B70 isolated the observable
dependency as follows:

- stock forcewake_all kept package temperature updating;
- a persistent main-GT XE_FW_RENDER reference kept it updating in three of
  three independent rounds;
- releasing that reference was followed by renewed staleness in all three
  rounds;
- main-GT XE_FW_GT alone was negative in the single persistent-holder round
  tested;
- transient XE_FW_RENDER acquisition produced a fresh value in 1.17 to
  2.172 ms; and
- a 20 ms RENDER hold with no sysfs reads yielded a fresh first read.

Acquire the main GT render forcewake domain around BMG package-temperature
reads, allow 3.0 to 3.5 ms for the observed publication to settle, read the
register, and release the reference automatically. The delay is empirical,
not an architectural contract. FORCEWAKE_ACK_RENDER only acknowledges the
wake domain; no public temperature-producer-ready indication was found.
These experiments do not establish that register 0x138434 architecturally
belongs to XE_FW_RENDER or identify whether PCODE, GuC, or other firmware
produces the value.

Keep the change limited to the BMG package-temperature channel. Runtime
validation was performed on one Arc Pro B70. XE_FW_RENDER was
single-domain sufficient among the directly compared states, but media,
GSC, and other individual forcewake domains were not tested after that
positive result. This does not claim that RENDER is the unique minimum for
all BMG devices or steppings.

The equivalent Ubuntu 7.0 diagnostic implementation passed three
independent 180-second cooldown rounds; 1, 5, 10, and 30 second read
cadences; four concurrent readers; a 30-minute run; OpenVINO workloads;
suspend/resume; and Xe unbind/rebind. The directly tested drm-tip
submission candidate, based on 75140c4ee9ad, additionally passed one
clpeak/dual-reader/180-second-cooldown smoke and one bounded OpenVINO
two-model smoke. No GPU hang, reset, fault, wedge, or kernel taint
occurred.

Fixes: dac328dea701 ("drm/xe/hwmon: expose package and vram temperature")
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7805
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4560
Assisted-by: OpenAI Codex:gpt-5.6-sol
Assisted-by: Claude Code:claude-fable-5
Assisted-by: ChatGPT:GPT-5.6 Sol Pro
Signed-off-by: Yuta Higuchi <avablaba@gmail.com>
---
 drivers/gpu/drm/xe/xe_hwmon.c | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/xe/xe_hwmon.c b/drivers/gpu/drm/xe/xe_hwmon.c
index 5284cab67..1c0c6d3ab 100644
--- a/drivers/gpu/drm/xe/xe_hwmon.c
+++ b/drivers/gpu/drm/xe/xe_hwmon.c
@@ -3,6 +3,7 @@
  * Copyright © 2023 Intel Corporation
  */
 
+#include <linux/delay.h>
 #include <linux/hwmon-sysfs.h>
 #include <linux/hwmon.h>
 #include <linux/jiffies.h>
@@ -14,6 +15,7 @@
 #include "regs/xe_mchbar_regs.h"
 #include "regs/xe_pcode_regs.h"
 #include "xe_device.h"
+#include "xe_force_wake.h"
 #include "xe_hwmon.h"
 #include "xe_mmio.h"
 #include "xe_pcode.h"
@@ -330,6 +332,28 @@ static struct xe_reg xe_hwmon_get_reg(struct xe_hwmon *hwmon, enum xe_hwmon_reg
 	return XE_REG(0);
 }
 
+/*
+ * Experiments on Arc Pro B70 show that package-temperature updates resume
+ * after acquiring the main GT render forcewake domain. Allow time for a fresh
+ * value before reading. FORCEWAKE_ACK_RENDER acknowledges the forcewake
+ * domain; it is not known to indicate temperature-producer readiness.
+ */
+static int xe_hwmon_bmg_pkg_temp_read(struct xe_hwmon *hwmon, u64 *reg_val)
+{
+	struct xe_force_wake *fw = gt_to_fw(xe_root_mmio_gt(hwmon->xe));
+	struct xe_mmio *mmio = xe_root_tile_mmio(hwmon->xe);
+
+	CLASS(xe_force_wake, fw_ref)(fw, XE_FW_RENDER);
+
+	if (!xe_force_wake_ref_has_domain(fw_ref.domains, XE_FW_RENDER))
+		return -ETIMEDOUT;
+
+	usleep_range(3000, 3500);
+	*reg_val = xe_mmio_read32(mmio, xe_hwmon_get_reg(hwmon, REG_TEMP, CHANNEL_PKG));
+
+	return 0;
+}
+
 #define PL_DISABLE 0
 
 /*
@@ -1037,6 +1061,17 @@ xe_hwmon_temp_read(struct xe_hwmon *hwmon, u32 attr, int channel, long *val)
 	case hwmon_temp_input:
 		switch (channel) {
 		case CHANNEL_PKG:
+			if (hwmon->xe->info.platform == XE_BATTLEMAGE) {
+				int ret = xe_hwmon_bmg_pkg_temp_read(hwmon, &reg_val);
+
+				if (ret)
+					return ret;
+
+				*val = REG_FIELD_GET(TEMP_MASK, reg_val) *
+				       MILLIDEGREE_PER_DEGREE;
+				return 0;
+			}
+			fallthrough;
 		case CHANNEL_VRAM:
 			reg_val = xe_mmio_read32(mmio, xe_hwmon_get_reg(hwmon, REG_TEMP, channel));
 
-- 
2.43.0

✗ LGCI.VerificationFailed: failure for drm/xe/hwmon: wake render domain for BMG package temperature

[Patchwork]

== Series Details ==

Series: drm/xe/hwmon: wake render domain for BMG package temperature
URL   : https://patchwork.freedesktop.org/series/172621/
State : failure

== Summary ==

Series author address 'avablaba@gmail.com' is not on the allowlist, which prevents CI from being automatically triggered.
If you want CI to run for this series, ask Patchwork project owners to click 'retest' on the series in Patchwork.
Exception occurred during validation, bailing out!
Build URL: http://intel-gfx-ci-public.igk.intel.com:8080/job/xe_pw_trigger/1257363/ (on master)

Re: [RFC PATCH 0/1] drm/xe/hwmon: wake render domain for BMG package temperature

[Yuta Higuchi]

Hello,

Following up on this RFC with additional measurements from two Arc Pro
B70 cards in a different host. A matched A-B-B-A comparison supports the
submitted read-scoped change: the difference between an ordinary package
read and a subsequent longer-wake reference was 11-18 C without the patch,
and 0-1 C with it, across 12 trials per arm.

Matched comparison
------------------
A was a 7.0.14 diagnostic kernel with unmodified hwmon; B was the same
source with the submitted 35-line patch. Only xe_hwmon.c differed in the
sources, and only LOCALVERSION differed in configuration. Both included
the same reference-pulse instrumentation. These were matched diagnostic
builds, not a stock Ubuntu versus patched-kernel comparison.

All four boots used DMC 2.6, GuC 70.58.0 and HuC 8.2.10. The original
August report used GuC 70.72.1, so this is not an otherwise identical
repeat of that environment. The two cards share one host; they are not
two independent platforms.

Each boot had six trials: two cards x three package-read schedules.
After a common reference pulse, 15 s baseline and 10 s OpenCL load,
each trial cooled for 150 s. During cooling, package was either unread,
read once at 30 s, or read every second from 30 through 89 s, then left
unread. Non-package temperatures and fan speed were sampled throughout;
no GPU jobs or diagnostic pulses were submitted during cooling. Each
arm included both forward and reverse trial order.

At 150 s I read package, applied a requested 20 ms RENDER reference
pulse, then read package again. The table lists reference minus first
read, with all six results from each boot in execution order:

  Boot  Arm   Differences (C)
  0     A     -17, -12, -18, -15, -18, -15
  1     B      +1,  +1,   0,  +1,   0,   0
  2     B      +1,  +1,  +1,   0,   0,  +1
  3     A     -11, -17, -13, -16, -12, -17

A's median difference was -15.5 C; B's was +1 C. B matched exactly in
five trials and the reference was 1 C higher in seven. B's second read
also used the patched path. This is agreement with a longer-wake
reference, not independent thermometry or an architectural freshness
guarantee. The 244 scheduled B reads during cooling had measured
ACK-complete-to-MMIO intervals of 3.034-3.609 ms; those are execution
checks, not 244 independent freshness comparisons.

Fan behavior and domain scope
-----------------------------
With B's single/periodic package reads, both cards slowed down. At
80-89 s, one card was at 715-716 rpm versus A's 3082-3215 rpm, and the
other at 1786-2148 versus 3334-3691 rpm. In B's four no-package-read
cooling trials, there was no comparable decrease. A single patched read
could sustain lower speed through the remaining cooling window. The
final combined read/reference operation could increase fan speed again.
This supports an effect on the observed thermal/fan state, but does not
establish an autonomous fan-control fix or its internal temperature input.

There is also an important update to the original GT-negative observation.
In separate unpatched-kernel tests on these two cards, both GT-only and
RENDER-only pulses of about 20 ms changed package/mctrl/PCIe readings and
were followed by fan slowdown, without GPU work or temperature reads
inside the pulse. A further exploratory test on one card observed
C6 -> C0 -> C6 with both domains; sham remained in C6. Each card/condition
in these pulse comparisons was tested once. The original persistent-
holder test had different conditions, but its negative GT result should
not be generalized into a RENDER-exclusive dependency. RC6 exit itself
has not been isolated from other effects common to forcewake.

Trace/accounting note
---------------------
All 24 A/B trials are retained, with no retries or exclusions. Trace
coverage matched 379,980 sensor/fan reads and found no external hwmon
readers during collection. The reference-pulse audit initially included
intentional neighboring reads in an overly broad userspace time window.
I preserved the original results and separately corrected the audit to
use traced function entry/exit, retaining the forcewake/ACK/duration and
in-pulse read checks. All trials passed the corrected condition audit;
measurement windows and values were unchanged. Raw traces, scripts and
per-trial tables are retained and can be provided if useful.

The main remaining question is still the documented wake/publication
requirement: is there an update-completion indication or an appropriate
refresh sequence instead of a fixed delay, and what domain should be
used? Guidance would help determine the correct scope of a driver fix.

Finally, the CI reply says this series was not run because my address
was outside the allowlist. If appropriate, could a project owner trigger
retest for series 172621?
https://patchwork.freedesktop.org/series/172621/

Thanks,
Yuta Higuchi


2026年8月22日(土) 17:53 Yuta Higuchi <avablaba@gmail.com>:
>
> Hello,
>
> This RFC addresses a reproducible stale package-temperature value on one Intel
> Arc Pro B70 (8086:e223). During GPU activity, temp2_input changes continuously.
> After the workload exits, it changes for only a short lifecycle burst and then
> remains fixed for more than 200 seconds during idle cooldown. Other telemetry,
> including VRAM, mctrl, PCIe, fan, energy, and runtime state, continues to move.
> An independent PID reading the same sysfs node sees the same result.
>
> The symptom reproduces after cold boot, without OpenVINO, with a standard
> clpeak workload, and on Linux 6.17, 7.0, 7.1.5, and 7.2-rc7 using the same
> official BMG firmware. Holding runtime PM active alone did not restore idle
> updates, and a controlled Xe reprobe did not restore continuous updates.
>
> The tested firmware is byte-identical after decompression to official
> linux-firmware main:
>
> - DMC 2.6, content SHA-256
>   76e3ec6ea3a53ce727e43b84f5ea14c55400a2d118dac356d4e12a3cfac06b4d;
> - GuC 70.72.1, content SHA-256
>   de81c75f46a127c33cd59f604d800e9ffc7ed3495967ba0d8767cd6985ab398b;
> - HuC 8.2.10, content SHA-256
>   747452aa8c4ed7760c68a80f3d913eafde9304d6f4db481e3f2aebb0a818bf15.
>
> Source path and causal isolation
> --------------------------------
>
> For BMG, temp2_input reaches BMG_PACKAGE_TEMPERATURE (0x138434) through
> xe_mmio_read32(). On the tested B70:
>
> - stock forcewake_all kept package temperature updating;
> - main-GT XE_FW_RENDER alone was sufficient in 3/3 independent persistent
>   holder rounds;
> - releasing the RENDER holder was followed immediately by renewed staleness in
>   3/3 rounds;
> - main-GT XE_FW_GT alone was negative in the single persistent-holder round
>   tested;
> - a transient RENDER acquisition produced the first fresh publication after
>   1.17 to 2.172 ms; and
> - after a 20 ms RENDER hold with no sysfs reads, the first package-temperature
>   read was already fresh.
>
> These observations support a wake/publication dependency rather than a
> collector or sysfs-reader problem. They do not establish that register
> 0x138434 architecturally belongs to XE_FW_RENDER, nor whether PCODE, GuC, or
> other firmware produces a shadow value.
>
> Proposed RFC behavior
> ---------------------
>
> For the BMG package-temperature channel only, acquire the main GT
> XE_FW_RENDER domain, wait 3.0 to 3.5 ms, read the mapped package-temperature
> register, and release the reference automatically. Forcewake acquisition
> failure is returned as -ETIMEDOUT, following existing Xe forcewake-ACK timeout
> precedent.
>
> The 3.0 to 3.5 ms settling interval is empirical. The maximum fresh transition
> latency observed in the transient tests was 2.172 ms. FORCEWAKE_ACK_RENDER is a
> wake-domain acknowledgement; it has not been shown to be a temperature
> producer-ready acknowledgement. The fixed delay is not presented as an
> architectural contract.
>
> Scope and known limitations
> ---------------------------
>
> Runtime validation was performed on one Arc Pro B70 (8086:e223). The RFC is
> scoped to Battlemage because the affected package-temperature path is
> BMG-specific; guidance on applicability to other BMG devices and steppings is
> welcome.
>
> XE_FW_RENDER was single-domain sufficient among the directly compared states.
> XE_FW_GT alone was tested once and was negative. Media, GSC, and other
> individual forcewake domains were not tested after the RENDER-only positive was
> established. This RFC does not claim that RENDER is the unique minimum among
> every possible domain combination.
>
> Validation
> ----------
>
> Extensive runtime validation was performed with the equivalent diagnostic
> implementation on Ubuntu 7.0:
>
> - three independent 180-second cooldown rounds;
> - 1, 5, 10, and 30 second read cadences;
> - four concurrent readers (240/240 successful reads);
> - 30 minutes of continuous operation;
> - OpenVINO ruri-v3 and bge-m3 requests;
> - suspend/resume; and
> - controlled Xe unbind/rebind.
>
> No GPU hang, reset, fault, or wedge occurred. Persistent RENDER forcewake had a
> large power cost, whereas read-scoped references allowed GT idle residency to
> advance. The displayed cur_freq remained 2800 MHz while act_freq was zero and
> GT C6/idle residency progressed, so cur_freq was classified as telemetry state
> rather than evidence of a physically busy GT.
>
> The rebased current-tree candidate was additionally smoke-tested directly as
> 7.2.0-b70rfc2+, based on drm-tip 75140c4ee9ad. With the standard clpeak
> workload, both a main reader and an independent PID observed package
> temperature continue from 46 C down to 44 C during a 180-second cooldown.
> act_freq was zero, GT entered C6, and idle residency advanced by 178.25
> seconds. A separate bounded candidate-kernel test returned HTTP 200 for
> OpenVINO ruri-v3 and bge-m3. No hang, reset, fault, wedge, or taint occurred.
> This direct smoke does not include the 30-minute, suspend/resume, or reprobe
> tests listed above; those were run only with the equivalent Ubuntu 7.0
> diagnostic implementation.
>
> On stock kernels, a separate operational workaround submits one warmed Intel
> ICD work-item / one Xe job every 30 seconds and reads temp2_input 50 ms later.
> That workaround refreshes snapshots but is not the proposed kernel behavior.
>
> Related issues
> --------------
>
> Primary: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7805
> Secondary: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4560
>
> Questions for maintainers
> -------------------------
>
> 1. Is 0x138434 a live sensor register, or a shadow value published by PCODE,
>    GuC, or other firmware?
> 2. Is there a documented producer-ready indication after XE_FW_RENDER is
>    acquired?
> 3. If not, what is the official minimum delay or refresh sequence for this
>    register?
>
> If an existing mechanism is available to trigger or wait for
> package-temperature publication, I would prefer that over the empirical
> settling delay used by this RFC.
>
> Coding-assistant disclosure
> ---------------------------
>
> AI coding assistants were used during this investigation and RFC preparation:
> Claude Code for the initial investigation and independent review of the patch
> against the current tree, OpenAI Codex for implementation, evidence collection
> and test orchestration, and ChatGPT GPT-5.6 Sol Pro for investigation planning,
> submission workflow design and review. The human submitter reviewed the
> resulting code and evidence and takes responsibility for the submission.
>
> Thanks,
> Yuta Higuchi
>
> Yuta Higuchi (1):
>   drm/xe/hwmon: wake render domain for BMG package temperature
>
>  drivers/gpu/drm/xe/xe_hwmon.c | 35 +++++++++++++++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
>
>
> base-commit: 75140c4ee9ad250b2524ff5bfffd7f9fe4bb6012
> --
> 2.43.0
>