]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
drm/i915/display: Fix dma_fence_wait_timeout() return value handling
authorAakash Deep Sarkar <aakash.deep.sarkar@intel.com>
Tue, 8 Jul 2025 07:45:40 +0000 (07:45 +0000)
committerRodrigo Vivi <rodrigo.vivi@intel.com>
Wed, 23 Jul 2025 13:12:22 +0000 (09:12 -0400)
commitfd77b2c1b6eb7c7d2087e2c2b37c671d47fd2d4f
treedcb20b2bea576f9cd59ed29e0bb38f9649da0c0b
parent9e0c433d0c05fde284025264b89eaa4ad59f0a3e
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
(cherry picked from commit cdb16039515a5ac4d2c923f7a651cf19a803a3fe)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
drivers/gpu/drm/i915/display/intel_display.c