[Intel-gfx] [PATCH] dma-buf: revert "return only unsignaled fences in dma_fence_unwrap_for_each v3"

Christian König christian.koenig at amd.com
Thu Jul 14 09:13:04 UTC 2022


Am 14.07.22 um 11:06 schrieb Thomas Zimmermann:
> Hi
>
> Am 14.07.22 um 10:49 schrieb Christian König:
>> Hi Thomas,
>>
>> Am 14.07.22 um 10:40 schrieb Thomas Zimmermann:
>>> Hi Christian
>>>
>>> Am 12.07.22 um 12:28 schrieb Christian König:
>>>> This reverts commit 8f61973718485f3e89bc4f408f929048b7b47c83.
>>>
>>> I only found this commit in drm-misc-next. Should the revert be 
>>> cherry-picked into drm-misc-next-fixes?
>>
>> yes for all three patches you just pinged me.
>>
>> I've already tried to push them to drm-misc-next-fixes, but the 
>> patches somehow wouldn't apply. I think the -next-fixes branch was 
>> somehow lagging behind.
>
> I just forwarded drm-misc-next-fixes to the latest state of drm-next. 
> Chances are, these patches will apply now.

Thanks, should I cherry pick them or are you going to do it?

And can we somehow make sure that when the drm-misc-next is merged into 
drm-next for upstreaming that drm-misc-next-fixes is up to date as well? 
That would make things much easier.

Thanks,
Christian.

>
> Best regards
> Thomas
>
>>
>> Thanks,
>> Christian.
>>
>>>
>>> Best regards
>>> Thomas
>>>
>>>>
>>>> It turned out that this is not correct. Especially the sync_file info
>>>> IOCTL needs to see even signaled fences to correctly report back their
>>>> status to userspace.
>>>>
>>>> Instead add the filter in the merge function again where it makes 
>>>> sense.
>>>>
>>>> Signed-off-by: Christian König <christian.koenig at amd.com>
>>>> ---
>>>>   drivers/dma-buf/dma-fence-unwrap.c | 3 ++-
>>>>   include/linux/dma-fence-unwrap.h   | 6 +-----
>>>>   2 files changed, 3 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/drivers/dma-buf/dma-fence-unwrap.c 
>>>> b/drivers/dma-buf/dma-fence-unwrap.c
>>>> index 502a65ea6d44..7002bca792ff 100644
>>>> --- a/drivers/dma-buf/dma-fence-unwrap.c
>>>> +++ b/drivers/dma-buf/dma-fence-unwrap.c
>>>> @@ -72,7 +72,8 @@ struct dma_fence 
>>>> *__dma_fence_unwrap_merge(unsigned int num_fences,
>>>>       count = 0;
>>>>       for (i = 0; i < num_fences; ++i) {
>>>>           dma_fence_unwrap_for_each(tmp, &iter[i], fences[i])
>>>> -            ++count;
>>>> +            if (!dma_fence_is_signaled(tmp))
>>>> +                ++count;
>>>>       }
>>>>         if (count == 0)
>>>> diff --git a/include/linux/dma-fence-unwrap.h 
>>>> b/include/linux/dma-fence-unwrap.h
>>>> index 390de1ee9d35..66b1e56fbb81 100644
>>>> --- a/include/linux/dma-fence-unwrap.h
>>>> +++ b/include/linux/dma-fence-unwrap.h
>>>> @@ -43,14 +43,10 @@ struct dma_fence *dma_fence_unwrap_next(struct 
>>>> dma_fence_unwrap *cursor);
>>>>    * Unwrap dma_fence_chain and dma_fence_array containers and deep 
>>>> dive into all
>>>>    * potential fences in them. If @head is just a normal fence only 
>>>> that one is
>>>>    * returned.
>>>> - *
>>>> - * Note that signalled fences are opportunistically filtered out, 
>>>> which
>>>> - * means the iteration is potentially over no fence at all.
>>>>    */
>>>>   #define dma_fence_unwrap_for_each(fence, cursor, head)            \
>>>>       for (fence = dma_fence_unwrap_first(head, cursor); fence;    \
>>>> -         fence = dma_fence_unwrap_next(cursor)) \
>>>> -        if (!dma_fence_is_signaled(fence))
>>>> +         fence = dma_fence_unwrap_next(cursor))
>>>>     struct dma_fence *__dma_fence_unwrap_merge(unsigned int 
>>>> num_fences,
>>>>                          struct dma_fence **fences,
>>>
>>
>



More information about the Intel-gfx mailing list