[Intel-gfx] [PATCH 6/6] dma-fence: Store the timestamp in the same union as the cb_list

[Koenig, Christian]

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