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