similar to: [PATCH 3/3] drm/virtio: drop virtio_gpu_fence_cleanup()

Just call drm_fence_put directly instead. Also set vgfb->fence to NULL after dropping the reference. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 1 - drivers/gpu/drm/virtio/virtgpu_fence.c | 8 -------- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 +- drivers/gpu/drm/virtio/virtgpu_plane.c | 6 ++++-- 4 files changed, 5 insertions(+),

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 <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 14

From: Gustavo Padovan <gustavo.padovan at collabora.co.uk> Refactor fence creation to remove the potential allocation failure from the cmd_submit and atomic_commit paths. Now the fence should be allocated first and just after we should proceed with the rest of the execution. Signed-off-by: Gustavo Padovan <gustavo.padovan at collabora.co.uk> --- drivers/gpu/drm/virtio/virtgpu_drv.h

From: Gustavo Padovan <gustavo.padovan at collabora.co.uk> Refactor fence creation to remove the potential allocation failure from the cmd_submit and atomic_commit paths. Now the fence should be allocated first and just after we should proceed with the rest of the execution. Signed-off-by: Gustavo Padovan <gustavo.padovan at collabora.co.uk> --- drivers/gpu/drm/virtio/virtgpu_drv.h

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 <robert.foss at collabora.com> Suggested-by: Emil Velikov <emil.velikov at collabora.com> --- This patch was suggested in this email thread: [PATCH] drm/virtio: allocate fences with

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 <robert.foss at collabora.com> Suggested-by: Emil Velikov <emil.velikov at collabora.com> Reviewed-by: Chia-I Wu <olvaffe at gmail.com> --- This patch was suggested in this email thread:

From: Chia-I Wu <olvaffe at gmail.com> [ Upstream commit efe2bf965522bf0796d413b47a2abbf81d471d6f ] 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(...,

From: Chia-I Wu <olvaffe at gmail.com> [ Upstream commit efe2bf965522bf0796d413b47a2abbf81d471d6f ] 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(...,

On Tue, Mar 24, 2015 at 05:07:18PM +0100, Gerd Hoffmann wrote: > From: Dave Airlie <airlied at gmail.com> > > This patch adds a kms driver for the virtio gpu. The xorg modesetting > driver can handle the device just fine, the framebuffer for fbcon is > there too. > > Qemu patches for the host side are under review currently. > > The pci version of the device

On Tue, Mar 24, 2015 at 05:07:18PM +0100, Gerd Hoffmann wrote: > From: Dave Airlie <airlied at gmail.com> > > This patch adds a kms driver for the virtio gpu. The xorg modesetting > driver can handle the device just fine, the framebuffer for fbcon is > there too. > > Qemu patches for the host side are under review currently. > > The pci version of the device

From: Dave Airlie <airlied at gmail.com> This patch adds a kms driver for the virtio gpu. The xorg modesetting driver can handle the device just fine, the framebuffer for fbcon is there too. Qemu patches for the host side are under review currently. The pci version of the device comes in two variants: with and without vga compatibility. The former has a extra memory bar for the vga

From: Dave Airlie <airlied at gmail.com> This patch adds a kms driver for the virtio gpu. The xorg modesetting driver can handle the device just fine, the framebuffer for fbcon is there too. Qemu patches for the host side are under review currently. The pci version of the device comes in two variants: with and without vga compatibility. The former has a extra memory bar for the vga

From: Dave Airlie <airlied at gmail.com> This patch adds a kms driver for the virtio gpu. The xorg modesetting driver can handle the device just fine, the framebuffer for fbcon is there too. Qemu patches for the host side are under review currently. The pci version of the device comes in two variants: with and without vga compatibility. The former has a extra memory bar for the vga

From: Dave Airlie <airlied at gmail.com> This patch adds a kms driver for the virtio gpu. The xorg modesetting driver can handle the device just fine, the framebuffer for fbcon is there too. Qemu patches for the host side are under review currently. The pci version of the device comes in two variants: with and without vga compatibility. The former has a extra memory bar for the vga

From: Dave Airlie <airlied at gmail.com> This patch adds a kms driver for the virtio gpu. The xorg modesetting driver can handle the device just fine, the framebuffer for fbcon is there too. Qemu patches for the host side are under review currently. The pci version of the device comes in two variants: with and without vga compatibility. The former has a extra memory bar for the vga

From: Dave Airlie <airlied at gmail.com> This patch adds a kms driver for the virtio gpu. The xorg modesetting driver can handle the device just fine, the framebuffer for fbcon is there too. Qemu patches for the host side are under review currently. The pci version of the device comes in two variants: with and without vga compatibility. The former has a extra memory bar for the vga

No need to have our own implementation, atomic helpers can do it for us. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 7 -- drivers/gpu/drm/virtio/virtgpu_display.c | 20 +-- drivers/gpu/drm/virtio/virtgpu_fb.c | 150 ----------------------- drivers/gpu/drm/virtio/Makefile | 2 +- 4 files changed, 3 insertions(+), 176

Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 3 +-- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 5 ++--- 3 files changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index d6cc1a92ca..4e522e0b59 100644 ---

Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 14 --- drivers/gpu/drm/virtio/virtgpu_display.c | 1 - drivers/gpu/drm/virtio/virtgpu_drv.c | 9 +- drivers/gpu/drm/virtio/virtgpu_fb.c | 191 ------------------------------- drivers/gpu/drm/virtio/virtgpu_kms.c | 8 -- 5 files changed, 8 insertions(+), 215 deletions(-)

Switch to the virtio_gpu_array_* helper workflow. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +-- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 50 +++++++++++--------------- drivers/gpu/drm/virtio/virtgpu_plane.c | 21 ++++++++--- drivers/gpu/drm/virtio/virtgpu_vq.c | 9 +++-- 4 files changed, 47 insertions(+), 37 deletions(-) diff