Am 17.08.19 um 17:27 schrieb Chris Wilson:
> Quoting Koenig, Christian (2019-08-17 16:20:12)
>> Am 17.08.19 um 16:47 schrieb Chris Wilson:
>>> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
>>> index 89d96e3e6df6..2c21115b1a37 100644
>>> --- a/drivers/dma-buf/dma-fence.c
>>> +++ b/drivers/dma-buf/dma-fence.c
>>> @@ -129,6 +129,7 @@ EXPORT_SYMBOL(dma_fence_context_alloc);
>>> int dma_fence_signal_locked(struct dma_fence *fence)
>>> {
>>> struct dma_fence_cb *cur, *tmp;
>>> + struct list_head cb_list;
>>>
>>> lockdep_assert_held(fence->lock);
>>>
>>> @@ -136,16 +137,16 @@ int dma_fence_signal_locked(struct dma_fence *fence)
>>> &fence->flags)))
>>> return -EINVAL;
>>>
>>> + /* Stash the cb_list before replacing it with the timestamp */
>>> + list_replace(&fence->cb_list, &cb_list);
>> Stashing the timestamp instead is probably less bytes to modify.
> My thinking was to pass the timestamp to the notify callbacks, we need
> to stash the list and set the timestamp first.
I don't see much of a reason for callbacks to use the timestamp, they
could just call ktime_get() and would most likely get the same or at
least a very close by value.
> Nothing that I'm aware of uses the timestamp (just the sync file debug
> which weston was considering using at one point)... So I guess we don't
> care? But I would say we should do that as a separate step in case
> someone does.
Yeah, agree.
Christian.
> -Chris
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
