[PATCH] drm/xe/hwmon: refresh Battlemage thermal telemetry under force-wake

[PATCH] drm/xe/hwmon: refresh Battlemage thermal telemetry under force-wake

[Constantinos Chalkias]

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.

Acquire the GT force-wake domain around Battlemage thermal MMIO reads
and allow a short settling interval before reading the register. Route
package, VRAM and VRAM-channel availability reads through the helper.

Testing showed that an immediate read, as well as a 100-300 us delay,
could leave telemetry stale. A 500-1000 us delay recovered correctly
across repeated inference-to-idle cycles.

The change is restricted to Battlemage, where the behavior has been
reproduced and validated.

Signed-off-by: Constantinos Chalkias <cch@e-psn.eu>
---
 drivers/gpu/drm/xe/xe_hwmon.c | 51 ++++++++++++++++++++++++++++++-----
 1 file changed, 45 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_hwmon.c b/drivers/gpu/drm/xe/xe_hwmon.c
index 5edeac961ec3..fee358ab9a6b 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"
@@ -946,14 +948,43 @@ static void xe_hwmon_get_voltage(struct xe_hwmon *hwmon, int channel, long *valu
 	*value = DIV_ROUND_CLOSEST(REG_FIELD_GET(VOLTAGE_MASK, reg_val) * 2500, SF_VOLTAGE);
 }
 
-static inline bool is_vram_ch_available(struct xe_hwmon *hwmon, int channel)
+static int xe_hwmon_temp_mmio_read(struct xe_hwmon *hwmon,
+				   struct xe_reg reg, u32 *reg_val)
 {
 	struct xe_mmio *mmio = xe_root_tile_mmio(hwmon->xe);
+
+	if (hwmon->xe->info.platform == XE_BATTLEMAGE) {
+		struct xe_gt *gt = xe_root_mmio_gt(hwmon->xe);
+
+		CLASS(xe_force_wake, fw_ref)(gt_to_fw(gt), XE_FW_GT);
+
+		if (!xe_force_wake_ref_has_domain(fw_ref.domains, XE_FW_GT))
+			return -ETIMEDOUT;
+
+		/*
+		 * Allow thermal telemetry to refresh after leaving RC6
+		 * before reading the temperature register.
+		 */
+		usleep_range(500, 1000);
+
+		*reg_val = xe_mmio_read32(mmio, reg);
+		return 0;
+	}
+
+	*reg_val = xe_mmio_read32(mmio, reg);
+
+	return 0;
+}
+
+static inline bool is_vram_ch_available(struct xe_hwmon *hwmon, int channel)
+{
 	int vram_id = channel - CHANNEL_VRAM_N;
 	struct xe_reg vram_reg;
+	u32 reg_val;
 
 	vram_reg = xe_hwmon_get_reg(hwmon, REG_TEMP, channel);
-	if (!xe_reg_is_valid(vram_reg) || !xe_mmio_read32(mmio, vram_reg))
+	if (!xe_reg_is_valid(vram_reg) ||
+	    xe_hwmon_temp_mmio_read(hwmon, vram_reg, &reg_val) || !reg_val)
 		return false;
 
 	/* Create label only for available vram channel */
@@ -1025,15 +1056,19 @@ xe_hwmon_temp_is_visible(struct xe_hwmon *hwmon, u32 attr, int channel)
 static int
 xe_hwmon_temp_read(struct xe_hwmon *hwmon, u32 attr, int channel, long *val)
 {
-	struct xe_mmio *mmio = xe_root_tile_mmio(hwmon->xe);
-	u64 reg_val;
+	u32 reg_val;
+	int ret;
 
 	switch (attr) {
 	case hwmon_temp_input:
 		switch (channel) {
 		case CHANNEL_PKG:
 		case CHANNEL_VRAM:
-			reg_val = xe_mmio_read32(mmio, xe_hwmon_get_reg(hwmon, REG_TEMP, channel));
+			ret = xe_hwmon_temp_mmio_read(hwmon,
+						      xe_hwmon_get_reg(hwmon, REG_TEMP, channel),
+						      &reg_val);
+			if (ret)
+				return ret;
 
 			/* HW register value is in degrees Celsius, convert to millidegrees. */
 			*val = REG_FIELD_GET(TEMP_MASK, reg_val) * MILLIDEGREE_PER_DEGREE;
@@ -1043,7 +1078,11 @@ xe_hwmon_temp_read(struct xe_hwmon *hwmon, u32 attr, int channel, long *val)
 		case CHANNEL_PCIE:
 			return get_pcie_temp(hwmon, val);
 		case CHANNEL_VRAM_N...CHANNEL_VRAM_N_MAX:
-			reg_val = xe_mmio_read32(mmio, xe_hwmon_get_reg(hwmon, REG_TEMP, channel));
+			ret = xe_hwmon_temp_mmio_read(hwmon,
+						      xe_hwmon_get_reg(hwmon, REG_TEMP, channel),
+						      &reg_val);
+			if (ret)
+				return ret;
 			/*
 			 * This temperature format is 24 bit [31:8] signed integer and 8 bit
 			 * [7:0] fraction.
-- 
2.56.0

Re: [PATCH] drm/xe/hwmon: refresh Battlemage thermal telemetry under force-wake

[Rodrigo Vivi]

On Mon, Oct 12, 2026 at 01:42:45PM +0300, Constantinos Chalkias wrote:
> 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.
> 
> Acquire the GT force-wake domain around Battlemage thermal MMIO reads
> and allow a short settling interval before reading the register. Route
> package, VRAM and VRAM-channel availability reads through the helper.
> 
> Testing showed that an immediate read, as well as a 100-300 us delay,
> could leave telemetry stale. A 500-1000 us delay recovered correctly
> across repeated inference-to-idle cycles.
> 
> The change is restricted to Battlemage, where the behavior has been
> reproduced and validated.
> 
> Signed-off-by: Constantinos Chalkias <cch@e-psn.eu>

Cc: Bata Roland Krisztián <batarolandkrisztian@gmail.com>

https://lore.kernel.org/intel-xe/179041811564.526373.13204522833274380927.b70-hwmon-rfc@gmail.com/

I believe you guys are facing the same dificulties and arriving to similar
conclusions.

If the consensus is that we need this forcewake, let's do it.

Let's just avoid duplication of efforts in here.

And thank you all for the contributions.

> ---
>  drivers/gpu/drm/xe/xe_hwmon.c | 51 ++++++++++++++++++++++++++++++-----
>  1 file changed, 45 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_hwmon.c b/drivers/gpu/drm/xe/xe_hwmon.c
> index 5edeac961ec3..fee358ab9a6b 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"
> @@ -946,14 +948,43 @@ static void xe_hwmon_get_voltage(struct xe_hwmon *hwmon, int channel, long *valu
>  	*value = DIV_ROUND_CLOSEST(REG_FIELD_GET(VOLTAGE_MASK, reg_val) * 2500, SF_VOLTAGE);
>  }
>  
> -static inline bool is_vram_ch_available(struct xe_hwmon *hwmon, int channel)
> +static int xe_hwmon_temp_mmio_read(struct xe_hwmon *hwmon,
> +				   struct xe_reg reg, u32 *reg_val)
>  {
>  	struct xe_mmio *mmio = xe_root_tile_mmio(hwmon->xe);
> +
> +	if (hwmon->xe->info.platform == XE_BATTLEMAGE) {
> +		struct xe_gt *gt = xe_root_mmio_gt(hwmon->xe);
> +
> +		CLASS(xe_force_wake, fw_ref)(gt_to_fw(gt), XE_FW_GT);
> +
> +		if (!xe_force_wake_ref_has_domain(fw_ref.domains, XE_FW_GT))
> +			return -ETIMEDOUT;
> +
> +		/*
> +		 * Allow thermal telemetry to refresh after leaving RC6
> +		 * before reading the temperature register.
> +		 */
> +		usleep_range(500, 1000);
> +
> +		*reg_val = xe_mmio_read32(mmio, reg);
> +		return 0;
> +	}
> +
> +	*reg_val = xe_mmio_read32(mmio, reg);
> +
> +	return 0;
> +}
> +
> +static inline bool is_vram_ch_available(struct xe_hwmon *hwmon, int channel)
> +{
>  	int vram_id = channel - CHANNEL_VRAM_N;
>  	struct xe_reg vram_reg;
> +	u32 reg_val;
>  
>  	vram_reg = xe_hwmon_get_reg(hwmon, REG_TEMP, channel);
> -	if (!xe_reg_is_valid(vram_reg) || !xe_mmio_read32(mmio, vram_reg))
> +	if (!xe_reg_is_valid(vram_reg) ||
> +	    xe_hwmon_temp_mmio_read(hwmon, vram_reg, &reg_val) || !reg_val)
>  		return false;
>  
>  	/* Create label only for available vram channel */
> @@ -1025,15 +1056,19 @@ xe_hwmon_temp_is_visible(struct xe_hwmon *hwmon, u32 attr, int channel)
>  static int
>  xe_hwmon_temp_read(struct xe_hwmon *hwmon, u32 attr, int channel, long *val)
>  {
> -	struct xe_mmio *mmio = xe_root_tile_mmio(hwmon->xe);
> -	u64 reg_val;
> +	u32 reg_val;
> +	int ret;
>  
>  	switch (attr) {
>  	case hwmon_temp_input:
>  		switch (channel) {
>  		case CHANNEL_PKG:
>  		case CHANNEL_VRAM:
> -			reg_val = xe_mmio_read32(mmio, xe_hwmon_get_reg(hwmon, REG_TEMP, channel));
> +			ret = xe_hwmon_temp_mmio_read(hwmon,
> +						      xe_hwmon_get_reg(hwmon, REG_TEMP, channel),
> +						      &reg_val);
> +			if (ret)
> +				return ret;
>  
>  			/* HW register value is in degrees Celsius, convert to millidegrees. */
>  			*val = REG_FIELD_GET(TEMP_MASK, reg_val) * MILLIDEGREE_PER_DEGREE;
> @@ -1043,7 +1078,11 @@ xe_hwmon_temp_read(struct xe_hwmon *hwmon, u32 attr, int channel, long *val)
>  		case CHANNEL_PCIE:
>  			return get_pcie_temp(hwmon, val);
>  		case CHANNEL_VRAM_N...CHANNEL_VRAM_N_MAX:
> -			reg_val = xe_mmio_read32(mmio, xe_hwmon_get_reg(hwmon, REG_TEMP, channel));
> +			ret = xe_hwmon_temp_mmio_read(hwmon,
> +						      xe_hwmon_get_reg(hwmon, REG_TEMP, channel),
> +						      &reg_val);
> +			if (ret)
> +				return ret;
>  			/*
>  			 * This temperature format is 24 bit [31:8] signed integer and 8 bit
>  			 * [7:0] fraction.
> -- 
> 2.56.0
> 

Re: [PATCH] drm/xe/hwmon: refresh Battlemage thermal telemetry under force-wake

[Constantinos Chalkias]

Hi Rodrigo,
Thanks for pointing this out. Yes, this appears to be the same issue, 
and I agree we should avoid parallel fixes.
My follow-up testing independently converged on a very similar result. I 
narrowed the workaround to CHANNEL_PKG only. A 500-1000 us GT force-wake 
interval was not reliable, while 3000-3500 us was.
In the most controlled test I disabled both hwmon pollers, stopped the 
inference workload, and the physical blower remained latched at high 
speed for more than five minutes while the GPU was otherwise idle. A 
single package-temperature read using XE_FW_GT with a 3000-3500 us 
interval immediately caused the blower to return to normal.
I also saw the later RFC follow-up showing that both GT-only and 
RENDER-only longer pulses could refresh the telemetry and were followed 
by fan slowdown, which seems consistent with this result.
I won't send a competing v2. I'm happy to contribute these measurements 
to the existing RFC effort and help test whatever implementation you 
prefer to converge on.
Thanks,
Constantinos

On 2026-10-14 23:12, Rodrigo Vivi wrote:
> On Mon, Oct 12, 2026 at 01:42:45PM +0300, Constantinos Chalkias wrote:
>> 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.
>> 
>> Acquire the GT force-wake domain around Battlemage thermal MMIO reads
>> and allow a short settling interval before reading the register. Route
>> package, VRAM and VRAM-channel availability reads through the helper.
>> 
>> Testing showed that an immediate read, as well as a 100-300 us delay,
>> could leave telemetry stale. A 500-1000 us delay recovered correctly
>> across repeated inference-to-idle cycles.
>> 
>> The change is restricted to Battlemage, where the behavior has been
>> reproduced and validated.
>> 
>> Signed-off-by: Constantinos Chalkias <cch@e-psn.eu>
> 
> Cc: Bata Roland Krisztián <batarolandkrisztian@gmail.com>
> 
> https://lore.kernel.org/intel-xe/179041811564.526373.13204522833274380927.b70-hwmon-rfc@gmail.com/
> 
> I believe you guys are facing the same dificulties and arriving to 
> similar
> conclusions.
> 
> If the consensus is that we need this forcewake, let's do it.
> 
> Let's just avoid duplication of efforts in here.
> 
> And thank you all for the contributions.
> 
>> ---
>>  drivers/gpu/drm/xe/xe_hwmon.c | 51 
>> ++++++++++++++++++++++++++++++-----
>>  1 file changed, 45 insertions(+), 6 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/xe/xe_hwmon.c 
>> b/drivers/gpu/drm/xe/xe_hwmon.c
>> index 5edeac961ec3..fee358ab9a6b 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"
>> @@ -946,14 +948,43 @@ static void xe_hwmon_get_voltage(struct xe_hwmon 
>> *hwmon, int channel, long *valu
>>  	*value = DIV_ROUND_CLOSEST(REG_FIELD_GET(VOLTAGE_MASK, reg_val) * 
>> 2500, SF_VOLTAGE);
>>  }
>> 
>> -static inline bool is_vram_ch_available(struct xe_hwmon *hwmon, int 
>> channel)
>> +static int xe_hwmon_temp_mmio_read(struct xe_hwmon *hwmon,
>> +				   struct xe_reg reg, u32 *reg_val)
>>  {
>>  	struct xe_mmio *mmio = xe_root_tile_mmio(hwmon->xe);
>> +
>> +	if (hwmon->xe->info.platform == XE_BATTLEMAGE) {
>> +		struct xe_gt *gt = xe_root_mmio_gt(hwmon->xe);
>> +
>> +		CLASS(xe_force_wake, fw_ref)(gt_to_fw(gt), XE_FW_GT);
>> +
>> +		if (!xe_force_wake_ref_has_domain(fw_ref.domains, XE_FW_GT))
>> +			return -ETIMEDOUT;
>> +
>> +		/*
>> +		 * Allow thermal telemetry to refresh after leaving RC6
>> +		 * before reading the temperature register.
>> +		 */
>> +		usleep_range(500, 1000);
>> +
>> +		*reg_val = xe_mmio_read32(mmio, reg);
>> +		return 0;
>> +	}
>> +
>> +	*reg_val = xe_mmio_read32(mmio, reg);
>> +
>> +	return 0;
>> +}
>> +
>> +static inline bool is_vram_ch_available(struct xe_hwmon *hwmon, int 
>> channel)
>> +{
>>  	int vram_id = channel - CHANNEL_VRAM_N;
>>  	struct xe_reg vram_reg;
>> +	u32 reg_val;
>> 
>>  	vram_reg = xe_hwmon_get_reg(hwmon, REG_TEMP, channel);
>> -	if (!xe_reg_is_valid(vram_reg) || !xe_mmio_read32(mmio, vram_reg))
>> +	if (!xe_reg_is_valid(vram_reg) ||
>> +	    xe_hwmon_temp_mmio_read(hwmon, vram_reg, &reg_val) || !reg_val)
>>  		return false;
>> 
>>  	/* Create label only for available vram channel */
>> @@ -1025,15 +1056,19 @@ xe_hwmon_temp_is_visible(struct xe_hwmon 
>> *hwmon, u32 attr, int channel)
>>  static int
>>  xe_hwmon_temp_read(struct xe_hwmon *hwmon, u32 attr, int channel, 
>> long *val)
>>  {
>> -	struct xe_mmio *mmio = xe_root_tile_mmio(hwmon->xe);
>> -	u64 reg_val;
>> +	u32 reg_val;
>> +	int ret;
>> 
>>  	switch (attr) {
>>  	case hwmon_temp_input:
>>  		switch (channel) {
>>  		case CHANNEL_PKG:
>>  		case CHANNEL_VRAM:
>> -			reg_val = xe_mmio_read32(mmio, xe_hwmon_get_reg(hwmon, REG_TEMP, 
>> channel));
>> +			ret = xe_hwmon_temp_mmio_read(hwmon,
>> +						      xe_hwmon_get_reg(hwmon, REG_TEMP, channel),
>> +						      &reg_val);
>> +			if (ret)
>> +				return ret;
>> 
>>  			/* HW register value is in degrees Celsius, convert to 
>> millidegrees. */
>>  			*val = REG_FIELD_GET(TEMP_MASK, reg_val) * MILLIDEGREE_PER_DEGREE;
>> @@ -1043,7 +1078,11 @@ xe_hwmon_temp_read(struct xe_hwmon *hwmon, u32 
>> attr, int channel, long *val)
>>  		case CHANNEL_PCIE:
>>  			return get_pcie_temp(hwmon, val);
>>  		case CHANNEL_VRAM_N...CHANNEL_VRAM_N_MAX:
>> -			reg_val = xe_mmio_read32(mmio, xe_hwmon_get_reg(hwmon, REG_TEMP, 
>> channel));
>> +			ret = xe_hwmon_temp_mmio_read(hwmon,
>> +						      xe_hwmon_get_reg(hwmon, REG_TEMP, channel),
>> +						      &reg_val);
>> +			if (ret)
>> +				return ret;
>>  			/*
>>  			 * This temperature format is 24 bit [31:8] signed integer and 8 
>> bit
>>  			 * [7:0] fraction.
>> --
>> 2.56.0
>> 

Re: [PATCH] drm/xe/hwmon: refresh Battlemage thermal telemetry under force-wake

[Simon Richter]

Hi,

On 10/15/26 5:12 AM, Rodrigo Vivi wrote:

> If the consensus is that we need this forcewake, let's do it.
It feels like we haven't really understood the problem yet, we just know 
something that appears to work.

If I run

     while true; do sleep 5 >forcewake_all; sleep 5; done & watch sensors

then the temperature sensors *do* update, but several of the VRAM 
channels take over a minute, so the long forcewake does not solve the 
problem. If shorter ones do, then I'd really like to understand why; my 
theory is that it's not the forcewake itself that does the job, but the 
fact that it's toggling, and possibly generating some events in some 
microcontroller. It may be sufficient to send some no-op commands 
instead of playing with the power rails.

Starting the loop above with pretty much everything at a nice toasty 
equilibrium temperature of 82 degrees (which is way too much IMO for a 
card that has no client connected and is just displaying a console 
login), the fans immediately come on, and apparently every ten seconds 
one of the VRAM channels updates to a lower temperature, so one 
forcewake event pretty much exactly corresponds to one sensor update.

That would explain why the patch works -- it generates the same number 
of forcewake events as sensor reads, and the delay makes sure they are 
registered as separate events. However, there is no correspondence 
between the event and the sensor, so if I do my normal telemetry 
recording (every sensor once every ten seconds) I can still get data 
that is ten seconds old, and I also wake up the GPU once every ten 
seconds even if there is nothing to do.

That is an improvement over the status quo, but my concern is that it 
will push us over into "good enough" territory where the actual problem 
is never addressed.

    Simon

Re: [PATCH] drm/xe/hwmon: refresh Battlemage thermal telemetry under force-wake

[Rodrigo Vivi]

On Thu, Oct 15, 2026 at 11:29:37AM +0900, Simon Richter wrote:
> Hi,
> 
> On 10/15/26 5:12 AM, Rodrigo Vivi wrote:
> 
> > If the consensus is that we need this forcewake, let's do it.
> It feels like we haven't really understood the problem yet, we just know
> something that appears to work.

Cc: karthik.poosa@intel.com
Cc: anshuman.gupta@intel.com

Do we have a gitlab issue filed on this already? It should be good to
consolidate all the view there. Furthermore, perhaps we can get some internal
help from FW teams to assist in here.

> 
> If I run
> 
>     while true; do sleep 5 >forcewake_all; sleep 5; done & watch sensors
> 
> then the temperature sensors *do* update, but several of the VRAM channels
> take over a minute, so the long forcewake does not solve the problem. If
> shorter ones do, then I'd really like to understand why; my theory is that
> it's not the forcewake itself that does the job, but the fact that it's
> toggling, and possibly generating some events in some microcontroller. It
> may be sufficient to send some no-op commands instead of playing with the
> power rails.

I wonder if some forcewake histeresis might help on this case as well...

Cc: Zongyao Bai <zongyao.bai@intel.com>
https://lore.kernel.org/intel-xe/20260601213804.707256-1-zongyao.bai@intel.com/

> 
> Starting the loop above with pretty much everything at a nice toasty
> equilibrium temperature of 82 degrees (which is way too much IMO for a card
> that has no client connected and is just displaying a console login), the
> fans immediately come on, and apparently every ten seconds one of the VRAM
> channels updates to a lower temperature, so one forcewake event pretty much
> exactly corresponds to one sensor update.
> 
> That would explain why the patch works -- it generates the same number of
> forcewake events as sensor reads, and the delay makes sure they are
> registered as separate events. However, there is no correspondence between
> the event and the sensor, so if I do my normal telemetry recording (every
> sensor once every ten seconds) I can still get data that is ten seconds old,
> and I also wake up the GPU once every ten seconds even if there is nothing
> to do.
> 
> That is an improvement over the status quo, but my concern is that it will
> push us over into "good enough" territory where the actual problem is never
> addressed.
> 
>    Simon

Re: [PATCH] drm/xe/hwmon: refresh Battlemage thermal telemetry under force-wake

[Simon Richter]

[-- Attachment #1.1: Type: text/plain, Size: 328 bytes --]

Hi,

On 10/15/26 21:47, Rodrigo Vivi wrote:

> Do we have a gitlab issue filed on this already? It should be good to
> consolidate all the view there. Furthermore, perhaps we can get some internal
> help from FW teams to assist in here.

Yes, https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/4560

    Simon

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]