summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorMichal Wajdeczko <michal.wajdeczko@intel.com>2026-09-04 19:05:30 +0200
committerMichal Wajdeczko <michal.wajdeczko@intel.com>2026-09-11 19:52:14 +0200
commit7dbd24e9d5311b6afdbdd875dd247ab5ff54edca (patch)
treea3804edc30fc406affef46c6e4bc875d0a43a67f /tools/perf/scripts/python
parenta158eba2fb0d82b7a11f316c6b4065d5861ba0dd (diff)
downloadlinux-7dbd24e9d5311b6afdbdd875dd247ab5ff54edca.tar.gz
linux-7dbd24e9d5311b6afdbdd875dd247ab5ff54edca.zip
drm/xe/log: Relax location ID recognition
It turned out that during early probe phase, VFs use detached from the xe_device, temporary xe_gt objects, which when used as location in xe_log() macros, will be treated by the dmesg decoration code as bogus, possibly triggering a WARN, and the output will look like: [drm] *ERROR* SIGID=104 (-ETIMEDOUT) LOC3.0? GUC: MMIO request ... instead of expected: [drm] *ERROR* SIGID=104 (-ETIMEDOUT) Tile0: GT0: GUC: MMIO request ... Relax the tile/GT id validation and instead of looking for the real objects, only check if encoded id is within the range of possible tiles or GTs on the current xe device, using data from the device descriptor rather then the object list. Fixes: 1151b9f6f465 ("drm/xe/log: Add component/location decorations to dmesg") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260904170531.516-7-michal.wajdeczko@intel.com
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions