On Mon, Jul 07, 2025 at 05:45:51AM +0000, Aakash Deep Sarkar wrote: > 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. > > Signed-off-by: Aakash Deep Sarkar <[email protected]>
Reviewed-by: Matthew Brost <[email protected]> > --- > drivers/gpu/drm/i915/display/intel_display.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index 456fc4b04cda..7035c1fc9033 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -7092,7 +7092,8 @@ static void intel_atomic_commit_fence_wait(struct > intel_atomic_state *intel_stat > struct drm_i915_private *i915 = to_i915(intel_state->base.dev); > struct drm_plane *plane; > struct drm_plane_state *new_plane_state; > - int ret, i; > + long ret; > + int i; > > for_each_new_plane_in_state(&intel_state->base, plane, new_plane_state, > i) { > if (new_plane_state->fence) { > -- > 2.49.0 >
