From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7BE3E3806B4 for ; Sat, 22 Aug 2026 08:53:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787388798; cv=none; b=W3VV+txlhR20FZ6Q8j+HYJ7NKXbUKTaZQly3YZ6CXZ0pjwJoBMMOOVz/NAYfaj/4GClXrj1q6LvdwB0i1o1KhVf307uqkYMzVxrREFS5aslHFuZJQR5fhTXuHg8TVz+bs5jPNlZWvXU8xjmDOk/yA9RQ9Huf+rVYIZ5paZa8pa4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787388798; c=relaxed/simple; bh=TZnNWrCx7eTZ/df0vznJ1l4b4SJ/rpxj/L+p0lZBeeE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=HVe3P+jTo7QUa8W35RPSv+BDnv0x6rJj6Ar/E73JTCLDvrex+9QevR2USk+o0CxvyDtESQdfv+iLDK7ARd/S/mxYIyYW9eFMaR/dDbmHyP79IMbxCTdhcQ4I8xJseGQsg7DCEuz/fCCnzUmqAXJemuXtRQGjy+PqsZVa5JETbS4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=cp7Qrum9; arc=none smtp.client-ip=209.85.214.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="cp7Qrum9" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2caea3f742bso29295585ad.0 for ; Sat, 22 Aug 2026 01:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787388795; x=1787993595; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=bR7LrEDWYTPsnuOnqVtcGLotVp78B6n1a5iwn0JbEJk=; b=cp7Qrum9S+08j7Lph245P32R/LEh9nBOypm9kajJZob9B7qjWAOMthumhaipuASkeI k0zs+sDw4bPbCEKVkE1VBl0363a4vxH/tXeks0kph/j9/MxTYhqEioXGVkNzM/G4l2GN ct3L5tQRddJlqkPSZ9/XiAL5Wix5V8EkKEk0XzaUcALwYJJU0xwh7kSZJJR7lmOLIZoc d05LKjszxdY6VNsQHT1KbtT9vGOSFyqqEAG72SwzEjc/yOzLtJdLj8JX1it8r3bNMpzf 6SCvavDn6V/s/dXaYQkQE1yI3FZbGPxOKmD47oPXW7d+wjjUxwV1sO5VoPbz/WT7O0kb fVLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787388795; x=1787993595; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=bR7LrEDWYTPsnuOnqVtcGLotVp78B6n1a5iwn0JbEJk=; b=hvQcZTyErG/VtWuOLryp1zduEj1lviybgZbunKziG4YtsaH7Kih6qd/GQKnuEWAX5c /dcM6qlCOwpB7EmwtL7/Z9HZpJL+Wn5A90tYqjh4oyxSQs1eFhBH+2gQ2uUS7fkooBfM kVThZY0BNkicmhI+8dEvv+x47wcEYTRJFrS3nCxfUc+aaPjQQJ/U+tG0Rjh7RBE9p8Y/ zsGsj/xQtdXqwDBl6/5u3GZo1iLusn0qdCqJUok/tCic8sn/OJVjL3Ht81hFWg1Q37SJ vbxEic1YtlzG2nWYrglu/80sNXGXVSGF92a1x1Y3HOzyCHfgq+C1KBnJlEvdgDr5KoEC 0P+w== X-Forwarded-Encrypted: i=1; AHgh+RqiPQPd/y3JPmdSNV7vNWHrPSv3e5fGMIMdjkYJuEBq393OfVFVVpMHQGzxTF9Wk/GGFlpeDotgzXwm6qI=@vger.kernel.org X-Gm-Message-State: AFuF++lWRk2gmCTOKIrizVlrVK3sRIiNZhGYrikch2w0jPu+8VruUsn9 +vvByelrWRO+5eEU0s3I90lNLkgq+3YoXZEugOn+wUITMYQGq3kZs0aU X-Gm-Gg: AR+sD11dJOyQG3ZqY+L9SPVRuzAcOM/dyjA8VWWbv1Y7WLN4Tz9/1NybDmzGICzWCm9 I9Ee9Qn7G9fhrEI7RHMr9UCsVASxCZPCERCmsRKq0woAZioLHBXd5F0mW93sYUtM9Dd6U/4roS9 xsRNqRHkVdrAXvHRc6yGl77lcw+IXVp132+P4HtBPWdJKG08/HwlmyP4TJdkzTnByZBVU3MSLy3 dBSIzvxJut+cSciU3ka/cNus9PDzUACyIlvXKS+qOdu4VePVa/GKQAzCi/XPDFpt5qSWRTI2qWg S1n5AJStrik2534hZ6Xn2acx2X15XZuIQfJWEEyBtmd2t/icqAwt/+qPYaCoVmcp4wBIgjdOkSf n1yaLRU8TmFuzf3TDCwbTi3JEaMDWwQidfGTtxftfK9ISaDyuFf+9QbMf5BBEQFin3Zbrzrawby 5TB4j/RJbaw4cIDKuvBaP+2wf5foekGtrS1nJe9IaZYAK1qxh+soDCO9SmC+6/icaAm+k9y/9Cr /Gajw7cN+eKOVc= X-Received: by 2002:a17:902:ec86:b0:2c6:9f66:d573 with SMTP id d9443c01a7336-2d64ae3ac9emr225062945ad.2.1787388795383; Sat, 22 Aug 2026 01:53:15 -0700 (PDT) Received: from mcp-node.. ([240d:f:fe4:c00:e9d:92ff:fe83:dbda]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d67676170fsm2982575ad.6.2026.08.22.01.53.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Aug 2026 01:53:14 -0700 (PDT) From: Yuta Higuchi To: intel-xe@lists.freedesktop.org Cc: Matthew Brost , =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Rodrigo Vivi , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [RFC PATCH 0/1] drm/xe/hwmon: wake render domain for BMG package temperature Date: Sat, 22 Aug 2026 17:52:02 +0900 Message-ID: X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello, This RFC addresses a reproducible stale package-temperature value on one In= tel Arc Pro B70 (8086:e223). During GPU activity, temp2_input changes continuou= sly. After the workload exits, it changes for only a short lifecycle burst and t= hen remains fixed for more than 200 seconds during idle cooldown. Other telemet= ry, including VRAM, mctrl, PCIe, fan, energy, and runtime state, continues to m= ove. 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-temperat= ure 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 time= out precedent. The 3.0 to 3.5 ms settling interval is empirical. The maximum fresh transit= ion 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 state= s. 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 h= ad 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 a= nd GT C6/idle residency progressed, so cur_freq was classified as telemetry st= ate 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 occurre= d. 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 lat= er. 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 preparatio= n: Claude Code for the initial investigation and independent review of the pat= ch against the current tree, OpenAI Codex for implementation, evidence collect= ion and test orchestration, and ChatGPT GPT-5.6 Sol Pro for investigation plann= ing, 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 --=20 2.43.0