Quoting Jason Ekstrand (2017-08-09 18:00:54)
> +static signed long drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs,
> + uint32_t count,
> + uint32_t flags,
> + signed long timeout,
> + uint32_t *idx)
> +{
> + struct syncobj_wait_entry *entries;
> + struct dma_fence *fence;
> + signed long ret;
> + uint32_t signaled_count, i;
> +
> + if (timeout == 0) {
> + signaled_count = 0;
> + for (i = 0; i < count; ++i) {
> + ret = drm_syncobj_signaled(syncobjs[i], flags);
> + if (ret < 0)
> + return ret;
> + if (ret == 0)
> + continue;
> + if (signaled_count == 0 && idx)
> + *idx = i;
> + signaled_count++;
> + }
> +
> + if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL)
> + return signaled_count == count ? 1 : 0;
> + else
> + return signaled_count > 0 ? 1 : 0;
There's a very annoying laxness in the dma_fence API here, in that
backends are not required to automatically report when a fence is
signaled prior to fence->ops->enable_signaling() being called.
So here if we fail to match signaled_count, we need to fallthough and
try a 0 timeout wait!
Christian, dma_fence_wait_any_timeout() has this same bug you told me off
for, e.g. commit 698c0f7ff216 ("dma-buf/fence: revert "don't wait when
specified timeout is zero" (v2)")!
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
