From: "Poosa, Karthik" <karthik.poosa@intel.com>
To: "Nilawar, Badal" <badal.nilawar@intel.com>,
<intel-xe@lists.freedesktop.org>
Cc: <rodrigo.vivi@intel.com>, <anshuman.gupta@intel.com>,
<raag.jadav@intel.com>, <riana.tauro@intel.com>,
<sk.anirban@intel.com>, <mallesh.koujalagi@intel.com>,
<soham.purkait@intel.com>
Subject: Re: [PATCH 1/3] drm/xe/hwmon: Detect unavailable temperature sensors
Date: Thu, 27 Aug 2026 10:46:35 +0530 [thread overview]
Message-ID: <34a0f5f1-f995-430d-912a-8e571be4089e@intel.com> (raw)
In-Reply-To: <16092cf0-2d78-49a8-a7a2-a333ed9c7e73@intel.com>
On 26-08-2026 17:20, Nilawar, Badal wrote:
>
> On 25-08-2026 00:11, Karthik Poosa wrote:
>> Add is_temp_valid() to validate sensor presence.
>> A temperature reading of 0xFF on CRI platforms indicates that the
>> corresponding sensor is not present and should be treated as
>> unavailable.
>>
>> Use this check from xe_hwmon_temp_is_visible() callback so that
>> attributes
>> for unavailable sensors are not exposed during hwmon device
>> registration.
>>
>> Signed-off-by: Karthik Poosa <karthik.poosa@intel.com>
>> ---
>> drivers/gpu/drm/xe/xe_hwmon.c | 79 +++++++++++++++++++++++++++++------
>> 1 file changed, 66 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_hwmon.c
>> b/drivers/gpu/drm/xe/xe_hwmon.c
>> index 5284cab6703d..2c4eba4b8f8f 100644
>> --- a/drivers/gpu/drm/xe/xe_hwmon.c
>> +++ b/drivers/gpu/drm/xe/xe_hwmon.c
>> @@ -813,12 +813,21 @@ static int
>> xe_hwmon_pcode_read_thermal_info(struct xe_hwmon *hwmon)
>> return ret;
>> }
>> +static inline bool is_temp_valid(const struct xe_hwmon *hwmon, u8
>> value)
>> +{
>> + /* Value of 0xFF indicates unavailable sensor for platforms from
>> CRI. */
>> + if (hwmon->xe->info.platform >= XE_CRESCENTISLAND)
>> + return value != U8_MAX;
>> + else
>> + return value != 0;
>
> How about returning true here?
for BMG value 0 will be there if temperature sensor is not there, which
is why we are checking this way.
>
>> +}
>> +
>> static int get_mc_temp(struct xe_hwmon *hwmon, long *val)
>> {
>> struct xe_tile *root_tile = xe_device_get_root_tile(hwmon->xe);
>> u32 *dword = (u32 *)hwmon->temp.value;
>> + int ret, i, count = 0;
>> s32 average = 0;
>> - int ret, i;
>> for (i = 0; i < DIV_ROUND_UP(TEMP_LIMIT_MAX, sizeof(u32));
>> i++) {
>> ret = xe_pcode_read(root_tile,
>> PCODE_MBOX(PCODE_THERMAL_INFO, READ_THERMAL_DATA, i),
>> @@ -828,11 +837,25 @@ static int get_mc_temp(struct xe_hwmon *hwmon,
>> long *val)
>> drm_dbg(&hwmon->xe->drm, "thermal data for group %d val
>> 0x%x\n", i, dword[i]);
>> }
>> - for (i = TEMP_INDEX_MCTRL; i < hwmon->temp.count - 1; i++)
>> - average += hwmon->temp.value[i];
>> + for (i = TEMP_INDEX_MCTRL; i < hwmon->temp.count - 1; i++) {
>> + if (is_temp_valid(hwmon, hwmon->temp.value[i])) {
>> + average += hwmon->temp.value[i];
>> + count++;
>> + } else {
>> + drm_dbg(&hwmon->xe->drm, "mc temp sensor %d not
>> available, val 0x%x\n",
>> + i, hwmon->temp.value[i]);
> Is this required?
i think we can have this debug log to know which memory controller
channel is available, of the available count
>> + }
>> + }
>> +
>> + if (!count) {
>> + drm_warn(&hwmon->xe->drm, "no memory temp sensors
>> available!\n");
>> + return -ENXIO;
> Why warning? If sensors are not available then its fine. This will any
> way avoid exposing attribute.
agree, sashiko also pointed to that, removing this is in next revision
>> + }
>> +
>> + average /= count;
>> + if (val)
>> + *val = average * MILLIDEGREE_PER_DEGREE;
>> - average /= (hwmon->temp.count - TEMP_INDEX_MCTRL - 1);
>> - *val = average * MILLIDEGREE_PER_DEGREE;
>> return 0;
>> }
>> @@ -852,7 +875,13 @@ static int get_pcie_temp(struct xe_hwmon
>> *hwmon, long *val)
>> data = REG_FIELD_GET(PCIE_SENSOR_MASK, data);
>> data = REG_FIELD_GET(TEMP_MASK, data);
>> - *val = (s8)data * MILLIDEGREE_PER_DEGREE;
>> + if (!is_temp_valid(hwmon, data)) {
>> + drm_warn(&hwmon->xe->drm, "pcie temp sensor not available,
>> val 0x%x\n", data);
>> + return -ENXIO;
> Ditto.
I shall remove this.
>> + }
>> +
>> + if (val)
>> + *val = (s8)data * MILLIDEGREE_PER_DEGREE;
>> return 0;
>> }
>> @@ -956,11 +985,21 @@ static inline bool is_vram_ch_available(struct
>> xe_hwmon *hwmon, int channel)
>> struct xe_mmio *mmio = xe_root_tile_mmio(hwmon->xe);
>> int vram_id = channel - CHANNEL_VRAM_N;
>> struct xe_reg vram_reg;
>> + u32 reg_val;
>> + u8 temp;
>> 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))
>> return false;
>> + reg_val = xe_mmio_read32(mmio, vram_reg);
>> + temp = REG_FIELD_GET(TEMP_MASK, reg_val);
>
> There is sashiko-bot warning on this. Need to fix.
>
> Thanks,
> Badal
agree, next revision will have the fix.
>
>> + if (!is_temp_valid(hwmon, temp)) {
>> + drm_dbg(&hwmon->xe->drm, "vram channel %d unavailable, val
>> 0x%x\n", vram_id,
>> + reg_val);
>> + return false;
>> + }
>> +
>> /* Create label only for available vram channel */
>> sprintf(hwmon->temp.vram_label[vram_id], "vram_ch_%d", vram_id);
>> return true;
>> @@ -977,8 +1016,9 @@ xe_hwmon_temp_is_visible(struct xe_hwmon *hwmon,
>> u32 attr, int channel)
>> case CHANNEL_VRAM:
>> return hwmon->temp.limit[TEMP_LIMIT_MEM_SHUTDOWN] ?
>> 0444 : 0;
>> case CHANNEL_MCTRL:
>> + return !get_mc_temp(hwmon, NULL) && hwmon->temp.count ?
>> 0444 : 0;
>> case CHANNEL_PCIE:
>> - return hwmon->temp.count ? 0444 : 0;
>> + return !get_pcie_temp(hwmon, NULL) && hwmon->temp.count
>> ? 0444 : 0;
>> case CHANNEL_VRAM_N...CHANNEL_VRAM_N_MAX:
>> return (is_vram_ch_available(hwmon, channel) &&
>> hwmon->temp.limit[TEMP_LIMIT_MEM_SHUTDOWN]) ? 0444
>> : 0;
>> @@ -992,8 +1032,9 @@ xe_hwmon_temp_is_visible(struct xe_hwmon *hwmon,
>> u32 attr, int channel)
>> case CHANNEL_VRAM:
>> return hwmon->temp.limit[TEMP_LIMIT_MEM_CRIT] ? 0444 : 0;
>> case CHANNEL_MCTRL:
>> + return !get_mc_temp(hwmon, NULL) && hwmon->temp.count ?
>> 0444 : 0;
>> case CHANNEL_PCIE:
>> - return hwmon->temp.count ? 0444 : 0;
>> + return !get_pcie_temp(hwmon, NULL) && hwmon->temp.count
>> ? 0444 : 0;
>> case CHANNEL_VRAM_N...CHANNEL_VRAM_N_MAX:
>> return (is_vram_ch_available(hwmon, channel) &&
>> hwmon->temp.limit[TEMP_LIMIT_MEM_CRIT]) ? 0444 : 0;
>> @@ -1011,12 +1052,24 @@ xe_hwmon_temp_is_visible(struct xe_hwmon
>> *hwmon, u32 attr, int channel)
>> case hwmon_temp_label:
>> switch (channel) {
>> case CHANNEL_PKG:
>> - case CHANNEL_VRAM:
>> - return xe_reg_is_valid(xe_hwmon_get_reg(hwmon, REG_TEMP,
>> - channel)) ? 0444 : 0;
>> + case CHANNEL_VRAM: {
>> + struct xe_mmio *mmio = xe_root_tile_mmio(hwmon->xe);
>> + struct xe_reg reg = xe_hwmon_get_reg(hwmon, REG_TEMP,
>> channel);
>> + u32 reg_val;
>> + u8 temp;
>> +
>> + if (!xe_reg_is_valid(reg))
>> + return 0;
>> +
>> + reg_val = xe_mmio_read32(mmio, reg);
>> + temp = REG_FIELD_GET(TEMP_MASK, reg_val);
>> +
>> + return is_temp_valid(hwmon, temp) ? 0444 : 0;
>> + }
>> case CHANNEL_MCTRL:
>> + return !get_mc_temp(hwmon, NULL) && hwmon->temp.count ?
>> 0444 : 0;
>> case CHANNEL_PCIE:
>> - return hwmon->temp.count ? 0444 : 0;
>> + return !get_pcie_temp(hwmon, NULL) && hwmon->temp.count
>> ? 0444 : 0;
>> case CHANNEL_VRAM_N...CHANNEL_VRAM_N_MAX:
>> return is_vram_ch_available(hwmon, channel) ? 0444 : 0;
>> default:
next prev parent reply other threads:[~2026-08-27 5:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 18:41 [PATCH 0/3] drm/xe/hwmon: Update hwmon thermal mailbox handling Karthik Poosa
2026-08-24 18:41 ` [PATCH 1/3] drm/xe/hwmon: Detect unavailable temperature sensors Karthik Poosa
2026-08-24 18:59 ` sashiko-bot
2026-08-25 6:45 ` Poosa, Karthik
2026-08-26 11:50 ` Nilawar, Badal
2026-08-27 5:16 ` Poosa, Karthik [this message]
2026-08-26 14:27 ` Raag Jadav
2026-08-26 20:20 ` Rodrigo Vivi
2026-08-24 18:41 ` [PATCH 2/3] drm/xe/hwmon: Use VRAM temperature sensor count from thermal config on CRI Karthik Poosa
2026-08-24 18:57 ` sashiko-bot
2026-08-25 7:22 ` Poosa, Karthik
2026-08-26 12:31 ` Nilawar, Badal
2026-08-26 18:19 ` Raag Jadav
2026-08-26 20:10 ` Rodrigo Vivi
2026-08-24 18:41 ` [PATCH 3/3] drm/xe/hwmon: Correct group selection for memory controller temperature Karthik Poosa
2026-08-24 18:54 ` sashiko-bot
2026-08-25 7:42 ` Poosa, Karthik
2026-08-24 18:41 ` [PATCH 0/3] drm/xe/hwmon: Update hwmon thermal mailbox handling Karthik Poosa
2026-08-24 18:41 ` [PATCH 1/3] drm/xe/hwmon: Detect unavailable temperature sensors Karthik Poosa
2026-08-24 18:58 ` sashiko-bot
2026-08-24 18:41 ` [PATCH 2/3] drm/xe/hwmon: Use VRAM temperature sensor count from thermal config on CRI Karthik Poosa
2026-08-24 18:56 ` sashiko-bot
2026-08-24 18:41 ` [PATCH 3/3] drm/xe/hwmon: Correct group selection for memory controller temperature Karthik Poosa
2026-08-24 18:57 ` sashiko-bot
2026-08-24 23:02 ` ✓ CI.KUnit: success for drm/xe/hwmon: Update hwmon thermal mailbox handling Patchwork
2026-08-24 23:59 ` ✗ Xe.CI.BAT: failure " Patchwork
2026-08-25 3:10 ` ✓ Xe.CI.FULL: success " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=34a0f5f1-f995-430d-912a-8e571be4089e@intel.com \
--to=karthik.poosa@intel.com \
--cc=anshuman.gupta@intel.com \
--cc=badal.nilawar@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=mallesh.koujalagi@intel.com \
--cc=raag.jadav@intel.com \
--cc=riana.tauro@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=sk.anirban@intel.com \
--cc=soham.purkait@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox