similar to: [PATCH 3/4] drm/virtio: add drm_driver.release callback.

Split virtio_gpu_deinit(), move the drm shutdown and release to virtio_gpu_release(). Also free vbufs in case we can't queue them. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++++ drivers/gpu/drm/virtio/virtgpu_kms.c | 5 +++++ drivers/gpu/drm/virtio/virtgpu_vq.c | 9 ++++++++- 4 files

Split virtio_gpu_deinit(), move the drm shutdown and release to virtio_gpu_release(). Also free vbufs in case we can't queue them. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + drivers/gpu/drm/virtio/virtgpu_display.c | 1 - drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++++ drivers/gpu/drm/virtio/virtgpu_kms.c | 5 +++++

Split virtio_gpu_deinit(), move the drm shutdown and release to virtio_gpu_release(). Drop vqs_ready variable, instead use drm_dev_{enter,exit,unplug} to avoid touching hardware after device removal. Tidy up here and there. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ++- drivers/gpu/drm/virtio/virtgpu_display.c | 1 -

On Tue, Feb 11, 2020 at 02:58:04PM +0100, Gerd Hoffmann wrote: > Split virtio_gpu_deinit(), move the drm shutdown and release to > virtio_gpu_release(). Drop vqs_ready variable, instead use > drm_dev_{enter,exit,unplug} to avoid touching hardware after > device removal. Tidy up here and there. > > v4: add changelog. > v3: use drm_dev_*(). > > Signed-off-by: Gerd

Split virtio_gpu_deinit(), move the drm shutdown and release to virtio_gpu_release(). Drop vqs_ready variable, instead use drm_dev_{enter,exit,unplug} to avoid touching hardware after device removal. Tidy up here and there. v4: add changelog. v3: use drm_dev_*(). Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ++-

Split virtio_gpu_deinit(), move the drm shutdown and release to virtio_gpu_release(). Drop vqs_ready variable, instead use drm_dev_{enter,exit,unplug} to avoid touching hardware after device removal. Tidy up here and there. v4: add changelog. v3: use drm_dev_*(). Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ++-

Make the queue functions return void, none of the call sites checks the return value. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_vq.c | 41 ++++++++++------------------- 1 file changed, 14 insertions(+), 27 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index 7ac20490e1b4..ca91e83ffaef 100644

Split virtqueue_kick() call into virtqueue_kick_prepare(), which requires serialization, and virtqueue_notify(), which does not. Move the virtqueue_notify() call out of the critical section protected by the queue lock. This avoids triggering a vmexit while holding the lock and thereby fixes a rather bad spinlock contention. Suggested-by: Chia-I Wu <olvaffe at gmail.com> Signed-off-by:

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

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

On Thu, Aug 29, 2019 at 11:01 PM Gerd Hoffmann <kraxel at redhat.com> wrote: > > Move object release into a separate worker. Releasing objects requires > sending commands to the host. Doing that in the dequeue worker will > cause deadlocks in case the command queue gets filled up, because the > dequeue worker is also the one which will free up slots in the command >

From: Dave Airlie <airlied at redhat.com> This should avoid issues with the fbdev path trying to render before we've gotten the display info. Signed-off-by: Dave Airlie <airlied at redhat.com> [ kraxel: wait for display-info reply ] Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + drivers/gpu/drm/virtio/virtgpu_kms.c | 4

From: Dave Airlie <airlied at redhat.com> This should avoid issues with the fbdev path trying to render before we've gotten the display info. Signed-off-by: Dave Airlie <airlied at redhat.com> [ kraxel: wait for display-info reply ] Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + drivers/gpu/drm/virtio/virtgpu_kms.c | 4

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