[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