kernel/linux.git/drivers/gpu/drm/virtio/virtgpu_fence.c, branch linux-5.3.y

drm/virtio: Remove redundant return type

2019-05-06T13:36:23+00:00

virtio_gpu_fence_emit() always returns 0, since it has no error paths. Consequently no calls for virtio_gpu_fence_emit() use the return value, and it can be removed. Signed-off-by: Robert Foss Reviewed-by: Chia-I Wu Link: http://patchwork.freedesktop.org/patch/msgid/20190506091034.30289-1-robert.foss@collabora.com Suggested-by: Emil Velikov Reviewed-by: Chia-I Wu Signed-off-by: Gerd Hoffmann

drm/virtio: allocate fences with GFP_KERNEL

2019-05-06T08:52:58+00:00

It was changed to GFP_ATOMIC in commit ec2f0577c (add & use virtio_gpu_queue_fenced_ctrl_buffer) because the allocation happened with a spinlock held. That was no longer true after commit 9fdd90c0f (add virtio_gpu_alloc_fence()). Signed-off-by: Chia-I Wu Reviewed-by: Robert Foss Reviewed-by: Emil Velikov Link: http://patchwork.freedesktop.org/patch/msgid/20190429221021.159784-1-olvaffe@gmail.com Cc: Gerd Hoffmann Cc: Gustavo Padovan Cc: Robert Foss Signed-off-by: Gerd Hoffmann

drm/virtio: trace drm_fence_emit

2019-05-06T08:52:58+00:00

For most drivers, drm_fence_init is followed by drm_fence_emit immediately. But for our driver, they are done separately. We also don't know the fence seqno until drm_fence_emit. Signed-off-by: Chia-I Wu Link: http://patchwork.freedesktop.org/patch/msgid/20190429220825.156644-2-olvaffe@gmail.com Signed-off-by: Gerd Hoffmann

drm/virtio: set seqno for dma-fence

2019-05-06T08:52:58+00:00

This is motivated by having meaningful ftrace events, but it also fixes use cases where dma_fence_is_later is called, such as in sync_file_merge. In other drivers, fence creation and cmdbuf submission normally happen atomically, mutex_lock(); fence = dma_fence_create(..., ++timeline->seqno); submit_cmdbuf(); mutex_unlock(); and have no such issue. But in our driver, because most ioctls queue commands into ctrlq, we do not want to grab a lock. Instead, we set seqno to 0 when a fence is created, and update it when the command is finally queued and the seqno is known. Signed-off-by: Chia-I Wu Reviewed-by: Emil Velikov Link: http://patchwork.freedesktop.org/patch/msgid/20190429220825.156644-1-olvaffe@gmail.com Signed-off-by: Gerd Hoffmann

drm/virtio: rework resource creation workflow.

2019-03-28T11:11:56+00:00

This patch moves the virtio_gpu_cmd_create_resource() call (which notifies the host about the new resource created) into the virtio_gpu_object_create() function. That way we can call virtio_gpu_cmd_create_resource() before ttm_bo_init(), so the host already knows about the object when ttm initializes the object and calls our driver callbacks. Specifically the object is already created when the virtio_gpu_ttm_tt_bind() callback invokes virtio_gpu_object_attach(), so the extra virtio_gpu_object_attach() calls done after virtio_gpu_object_create() are not needed any more. The fence support for the create ioctl becomes a bit more tricky though. The code moved into virtio_gpu_object_create() too. We first submit the (fenced) virtio_gpu_cmd_create_resource() command, then initialize the ttm object, and finally attach just created object to the fence for the command in case it didn't finish yet. Signed-off-by: Gerd Hoffmann Acked-by: Noralf Trønnes Link: http://patchwork.freedesktop.org/patch/msgid/20190318113332.10900-6-kraxel@redhat.com

drm/virtio: drop virtio_gpu_fence_cleanup()

2019-01-08T11:00:01+00:00

Just call drm_fence_put directly instead. Also set vgfb->fence to NULL after dropping the reference. Signed-off-by: Gerd Hoffmann Reviewed-by: Ezequiel Garcia Link: http://patchwork.freedesktop.org/patch/msgid/20181219122708.4586-4-kraxel@redhat.com

drm/virtio: fence: pass plain pointer

2018-11-29T12:45:07+00:00

Since commit "9fdd90c0f4 drm/virtio: add virtio_gpu_alloc_fence()" fences are not allocated any more by virtio_gpu_fence_emit(). So there is no need to pass down a reference to the fence pointer, a plain pointer is enough now. Convert virtio_gpu_fence_emit() and callers. Signed-off-by: Gerd Hoffmann Reviewed-by: Robert Foss Link: http://patchwork.freedesktop.org/patch/msgid/20181128151021.29565-2-kraxel@redhat.com

drm/virtio: add virtio_gpu_alloc_fence()

2018-11-14T13:21:01+00:00

Refactor fence creation, add fences to relevant GPU operations and add cursor helper functions. This removes the potential for allocation failures from the cmd_submit and atomic_commit paths. Now a fence will be allocated first and only after that will we proceed with the rest of the execution. Signed-off-by: Gustavo Padovan Signed-off-by: Robert Foss Link: http://patchwork.freedesktop.org/patch/msgid/20181112165157.32765-2-robert.foss@collabora.com Suggested-by: Rob Herring Signed-off-by: Gerd Hoffmann

drm/virtio: Remove unecessary dma_fence_ops

2018-07-03T11:14:18+00:00

dma_fence_default_wait is the default now, same for the trivial enable_signaling implementation. Reviewed-by: Eric Anholt Signed-off-by: Daniel Vetter Cc: David Airlie Cc: Gerd Hoffmann Cc: virtualization@lists.linux-foundation.org Link: https://patchwork.freedesktop.org/patch/msgid/20180503142603.28513-15-daniel.vetter@ffwll.ch

dma-buf: Rename struct fence to dma_fence

2016-10-25T12:40:39+00:00

I plan to usurp the short name of struct fence for a core kernel struct, and so I need to rename the specialised fence/timeline for DMA operations to make room. A consensus was reached in https://lists.freedesktop.org/archives/dri-devel/2016-July/113083.html that making clear this fence applies to DMA operations was a good thing. Since then the patch has grown a bit as usage increases, so hopefully it remains a good thing! (v2...: rebase, rerun spatch) v3: Compile on msm, spotted a manual fixup that I broke. v4: Try again for msm, sorry Daniel coccinelle script: @@ @@ - struct fence + struct dma_fence @@ @@ - struct fence_ops + struct dma_fence_ops @@ @@ - struct fence_cb + struct dma_fence_cb @@ @@ - struct fence_array + struct dma_fence_array @@ @@ - enum fence_flag_bits + enum dma_fence_flag_bits @@ @@ ( - fence_init + dma_fence_init | - fence_release + dma_fence_release | - fence_free + dma_fence_free | - fence_get + dma_fence_get | - fence_get_rcu + dma_fence_get_rcu | - fence_put + dma_fence_put | - fence_signal + dma_fence_signal | - fence_signal_locked + dma_fence_signal_locked | - fence_default_wait + dma_fence_default_wait | - fence_add_callback + dma_fence_add_callback | - fence_remove_callback + dma_fence_remove_callback | - fence_enable_sw_signaling + dma_fence_enable_sw_signaling | - fence_is_signaled_locked + dma_fence_is_signaled_locked | - fence_is_signaled + dma_fence_is_signaled | - fence_is_later + dma_fence_is_later | - fence_later + dma_fence_later | - fence_wait_timeout + dma_fence_wait_timeout | - fence_wait_any_timeout + dma_fence_wait_any_timeout | - fence_wait + dma_fence_wait | - fence_context_alloc + dma_fence_context_alloc | - fence_array_create + dma_fence_array_create | - to_fence_array + to_dma_fence_array | - fence_is_array + dma_fence_is_array | - trace_fence_emit + trace_dma_fence_emit | - FENCE_TRACE + DMA_FENCE_TRACE | - FENCE_WARN + DMA_FENCE_WARN | - FENCE_ERR + DMA_FENCE_ERR ) ( ... ) Signed-off-by: Chris Wilson Reviewed-by: Gustavo Padovan Acked-by: Sumit Semwal Acked-by: Christian König Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20161025120045.28839-1-chris@chris-wilson.co.uk