summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/sctop.py
diff options
context:
space:
mode:
authorAakash Deep Sarkar <aakash.deep.sarkar@intel.com>2025-07-08 07:45:40 +0000
committerAnkit Nautiyal <ankit.k.nautiyal@intel.com>2025-07-23 15:22:19 +0530
commitcdb16039515a5ac4d2c923f7a651cf19a803a3fe (patch)
tree4387d5084e551dd6a4efe1995c704f8dd455fcff /tools/perf/scripts/python/sctop.py
parent8921dce70d46e3156b5a0b21675f5ac90903d81d (diff)
drm/i915/display: Fix dma_fence_wait_timeout() return value handling
dma_fence_wait_timeout returns a long type but the driver is only using the lower 32 bits of the retval and discarding the upper 32 bits. This is particularly problematic if there are already signalled or stub fences on some of the hw planes. In this case the dma_fence_wait_timeout function will immediately return with timeout value MAX_SCHEDULE_TIMEOUT (0x7fffffffffffffff) since the fence is already signalled. If the driver only uses the lower 32 bits of this return value then it'll interpret it as an error code (0xFFFFFFFF or (-1)) and skip the wait on the remaining fences. This issue was first observed in the xe driver with the Android compositor where the GPU composited layer was not properly waited on when there were stub fences in other overlay planes resulting in visual artifacts. Fixes: d59cf7bb73f3c ("drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence") Signed-off-by: Aakash Deep Sarkar <aakash.deep.sarkar@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250708074540.1948068-1-aakash.deep.sarkar@intel.com
Diffstat (limited to 'tools/perf/scripts/python/sctop.py')
0 files changed, 0 insertions, 0 deletions