linux.git/drivers/gpu/drm/virtio/virtgpu_fence.c, branch v5.5

drm/virtio: add fence sanity check

2019-09-04T04:54:12+00:00

Make sure we don't leak half-initialized fences outside the driver.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Chia-I Wu 
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-19-kraxel@redhat.com

drm/virtgpu: drop use of drmP.h

2019-07-15T16:11:31+00:00

Drop use of the deprecated drmP.h header file.
Fix fallout by adding missing include files.

Signed-off-by: Sam Ravnborg 
Acked-by: Gerd Hoffmann 
Acked-by: Emil Velikov 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: virtualization@lists.linux-foundation.org
Link: https://patchwork.freedesktop.org/patch/msgid/20190630061922.7254-28-sam@ravnborg.org

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