According to the docs, dma_fence_wait_timeout() returns "0 if the wait
timed out," ... "Other error values may be returned on custom
implementations." While it is not quite clear if a custom implementation
is allowed to return "other error" instead of 0, it is rather clear that 0
return value should always mean that the wait timed out before the fence
got signaled.
i915 implementation of dma_fence_ops.wait() used with request fences,
which is a transparent wrapper around i915_request_wait_timeout(), returns
-ETIME if the wait has timed out -- that may be considered as acceptable.
However, it can return 0 in a rare case when the fence has been found
signaled right after no more wait time was left, and that's not compatible
with expectations of dma-fence and its users.
Since other users of i915_request_wait_timeout() may interpret 0 return
value as success, don't touch it, update the i915_fence_wait() wrapper
instead. Return 1 instead of 0, but keep -ETIME in case of timeout since
some i915 users of dma_fence_wait_timeout() may expect it.
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@xxxxxxxxxxxxxxx>
---
drivers/gpu/drm/i915/i915_request.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index f949a9495758a..451456ab1ddef 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -102,7 +102,7 @@ static signed long i915_fence_wait(struct dma_fence *fence,
{
return i915_request_wait_timeout(to_request(fence),
interruptible | I915_WAIT_PRIORITY,
- timeout);
+ timeout) ?: 1;
}
struct kmem_cache *i915_request_slab_cache(void)
--
2.25.1
