[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