linux.git/drivers/gpu/drm/virtio, branch v6.5

drm/virtio: Wait for each dma-fence of in-fence array individually

2023-06-03T01:50:50+00:00

Use dma-fence-unwrap API for waiting each dma-fence of the in-fence array
individually. Sync file's in-fence array always has a non-matching fence
context ID, which doesn't allow to skip waiting of fences with a matching
context ID in a case of a merged sync file fence.

Suggested-by: Rob Clark 
Reviewed-by: Emil Velikov 
Tested-by: Pierre-Eric Pelloux-Prayer 
Signed-off-by: Dmitry Osipenko 
Link: https://patchwork.freedesktop.org/patch/msgid/20230416115237.798604-3-dmitry.osipenko@collabora.com

drm/virtio: Refactor and optimize job submission code path

2023-06-03T01:50:40+00:00

Move virtio_gpu_execbuffer_ioctl() into separate virtgpu_submit.c file,
refactoring and optimizing the code along the way to ease addition of new
features to the ioctl.

The optimization is done by using optimal ordering of the job's submission
steps, reducing code path from the start of the ioctl to the point of
pushing job to virtio queue. Job's initialization is now performed before
in-fence is awaited and out-fence setup is made after sending out job to
virtio.

Reviewed-by: Rob Clark 
Reviewed-by: Emil Velikov 
Tested-by: Pierre-Eric Pelloux-Prayer 
Signed-off-by: Dmitry Osipenko 
Link: https://patchwork.freedesktop.org/patch/msgid/20230416115237.798604-2-dmitry.osipenko@collabora.com

Merge v6.3-rc4 into drm-next

2023-03-29T14:00:23+00:00

I just landed the fence deadline PR from Rob that a bunch of drivers
want/need to apply driver-specific patches. Backmerge -rc4 so that
they don't have to be stuck on -rc2 for no reason at all.

Signed-off-by: Daniel Vetter

drm/virtio: Enable fb damage clips property for the primary plane

2023-03-13T17:22:24+00:00

Christian Hergert reports that the driver doesn't enable the property and
that leads to always doing a full plane update, even when the driver does
support damage clipping for the primary plane.

Don't enable it for the cursor plane, because its .atomic_update callback
doesn't handle damage clips.

Reported-by: Christian Hergert 
Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Thomas Zimmermann 
Acked-by: Gerd Hoffmann 
Link: https://patchwork.freedesktop.org/patch/msgid/20230310125943.912514-1-javierm@redhat.com

Merge drm/drm-fixes into drm-misc-fixes

2023-03-13T09:14:05+00:00

Backmerging to get latest upstream.

Signed-off-by: Thomas Zimmermann

Merge drm/drm-next into drm-misc-next

2023-03-13T08:27:50+00:00

Backmerging to get v6.3-rc1 and sync with the other DRM trees.

Signed-off-by: Thomas Zimmermann

drm/virtio: Fix handling CONFIG_DRM_VIRTIO_GPU_KMS option

2023-03-06T17:32:17+00:00

VirtIO-GPU got a new config option for disabling KMS. There were two
problems left unnoticed during review when the new option was added:

1. The IS_ENABLED(CONFIG_DRM_VIRTIO_GPU_KMS) check in the code was
inverted, hence KMS was disabled when it should be enabled and vice versa.

2. The disabled KMS crashed kernel with a NULL dereference in
drm_kms_helper_hotplug_event(), which shall not be invoked with a
disabled KMS.

Fix the inverted config option check in the code and skip handling the
VIRTIO_GPU_EVENT_DISPLAY sent by host when KMS is disabled in guest to fix
the crash.

Acked-by: Gerd Hoffmann 
Reviewed-by: Emil Velikov 
Fixes: 72122c69d717 ("drm/virtio: Add option to disable KMS support")
Signed-off-by: Dmitry Osipenko 
Link: https://patchwork.freedesktop.org/patch/msgid/20230306163916.1595961-1-dmitry.osipenko@collabora.com

drm/virtio: Add option to disable KMS support

2023-03-03T20:29:54+00:00

Add a build option to disable modesetting support.  This is useful in
cases where the guest only needs to use the GPU in a headless mode, or
(such as in the CrOS usage) window surfaces are proxied to a host
compositor.

As the modesetting ioctls are a big surface area for potential security
bugs to be found (it's happened in the past, we should assume it will
again in the future), it makes sense to have a build option to disable
those ioctls in cases where they serve no legitimate purpose.

v2: Use more if (IS_ENABLED(...))
v3: Also permit the host to advertise no scanouts
v4: Spiff out commit msg
v5: Make num_scanouts==0 and DRM_VIRTIO_GPU_KMS=n behave the same
v6: Drop conditionally building virtgpu_display.c and early-out of
    it's init/fini fxns instead

Signed-off-by: Rob Clark 
Reviewed-by: Dmitry Osipenko 
Reviewed-by: Javier Martinez Canillas 
Reviewed-by: Gerd Hoffmann 
Signed-off-by: Dmitry Osipenko 
Link: https://patchwork.freedesktop.org/patch/msgid/20230302233506.3146290-1-robdclark@gmail.com

drm/virtio: use strscpy() to instead of strncpy()

2023-02-26T23:58:50+00:00

The implementation of strscpy() is more robust and safer.
That's now the recommended way to copy NUL terminated strings.

Signed-off-by: Xu Panda 
Signed-off-by: Yang Yang 
Signed-off-by: Dmitry Osipenko 
Link: https://patchwork.freedesktop.org/patch/msgid/202212070913161959936@zte.com.cn

drm/virtio: Pass correct device to dma_sync_sgtable_for_device()

2023-02-26T23:39:24+00:00

The "vdev->dev.parent" should be used instead of "vdev->dev" as a device
for which to perform the DMA operation in both
virtio_gpu_cmd_transfer_to_host_2d(3d).

Because the virtio-gpu device "vdev->dev" doesn't really have DMA OPS
assigned to it, but parent (virtio-pci or virtio-mmio) device
"vdev->dev.parent" has. The more, the sgtable in question the code is
trying to sync here was mapped for the parent device (by using its DMA OPS)
previously at:
virtio_gpu_object_shmem_init()->drm_gem_shmem_get_pages_sgt()->
dma_map_sgtable(), so should be synced here for the same parent device.

Fixes: b5c9ed70d1a9 ("drm/virtio: Improve DMA API usage for shmem BOs")
Signed-off-by: Oleksandr Tyshchenko 
Reviewed-by: Dmitry Osipenko 
Signed-off-by: Dmitry Osipenko 
Link: https://patchwork.freedesktop.org/patch/msgid/20230224153450.526222-1-olekstysh@gmail.com