Skip to content
Commit 9a031265 authored by Erik Kurzinger's avatar Erik Kurzinger Committed by Greg Kroah-Hartman
Browse files

drm/syncobj: call drm_syncobj_fence_add_wait when WAIT_AVAILABLE flag is set

[ Upstream commit 3c43177f ]

When waiting for a syncobj timeline point whose fence has not yet been
submitted with the WAIT_FOR_SUBMIT flag, a callback is registered using
drm_syncobj_fence_add_wait and the thread is put to sleep until the
timeout expires. If the fence is submitted before then,
drm_syncobj_add_point will wake up the sleeping thread immediately which
will proceed to wait for the fence to be signaled.

However, if the WAIT_AVAILABLE flag is used instead,
drm_syncobj_fence_add_wait won't get called, meaning the waiting thread
will always sleep for the full timeout duration, even if the fence gets
submitted earlier. If it turns out that the fence *has* been submitted
by the time it eventually wakes up, it will still indicate to userspace
that the wait completed successfully (it won't return -ETIME), but it
will have taken much longer than it should have.

To fix this, we must call drm_syncobj_fence_add_wait if *either* the
WAIT_FOR_SUBMIT flag or the WAIT_AVAILABLE flag is set. The only
difference being that with WAIT_FOR_SUBMIT we will also wait for the
fence to be signaled after it has been submitted while with
WAIT_AVAILABLE we will return immediately.

IGT test patch: https://lists.freedesktop.org/archives/igt-dev/2024-January/067537.html



v1 -> v2: adjust lockdep_assert_none_held_once condition

(cherry picked from commit 8c44ea81)

Fixes: 01d6c357 ("drm/syncobj: add support for timeline point wait v8")
Signed-off-by: default avatarErik Kurzinger <ekurzinger@nvidia.com>
Signed-off-by: default avatarSimon Ser <contact@emersion.fr>
Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: default avatarSimon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20240119163208.3723457-1-ekurzinger@nvidia.com


Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
parent 13b57b5c
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment