kernel/linux.git/drivers/gpu/drm/virtio, branch v5.12.1

drm/virtio: fix an error code in virtio_gpu_init()

2021-02-09T16:16:57+00:00

If devm_request_mem_region() fails this code currently returns success but it should return -EBUSY. Fixes: 6076a9711dc5 ("drm/virtio: implement blob resources: probe for host visible region") Signed-off-by: Dan Carpenter Link: http://patchwork.freedesktop.org/patch/msgid/YBpy0GS7GfmafMfe@mwanda Signed-off-by: Gerd Hoffmann (cherry picked from commit eb988a2ee500d3297a1de048dc3c77b6c354e650) Signed-off-by: Maarten Lankhorst

drm/virtio: fix prime export for vram objects

2021-01-11T07:49:48+00:00

commit 16845c5d5409 ("drm/virtio: implement blob resources: implement vram object") and commit c6069a02fa55 ("drm/virtgpu: Set PRIME export function in struct drm_gem_object_funcs") landed from different trees, resulting in prime export never working for vram objects. Cc: Gurchetan Singh Cc: Thomas Zimmermann Cc: Gerd Hoffmann Signed-off-by: Chia-I Wu Reviewed-by: Gurchetan Singh Link: http://patchwork.freedesktop.org/patch/msgid/20210107210743.269885-1-olvaffe@gmail.com Signed-off-by: Gerd Hoffmann

drm/virtio: make sure context is created in gem open

2021-01-11T07:49:48+00:00

The context might still be missing when DRM_IOCTL_PRIME_FD_TO_HANDLE is the first ioctl on the drm_file. Fixes: 72b48ae800da ("drm/virtio: enqueue virtio_gpu_create_context after the first 3D ioctl") Cc: Gurchetan Singh Cc: Gerd Hoffmann Signed-off-by: Chia-I Wu Link: http://patchwork.freedesktop.org/patch/msgid/20210107210726.269584-1-olvaffe@gmail.com Reviewed-by: Gurchetan Singh Signed-off-by: Gerd Hoffmann

drm/virtgpu: Remove references to struct drm_device.pdev

2021-01-06T14:44:04+00:00

Using struct drm_device.pdev is deprecated. Convert virtgpu to struct drm_device.dev. No functional changes. Signed-off-by: Thomas Zimmermann Acked-by: Gerd Hoffmann Acked-by: Sam Ravnborg Cc: Gerd Hoffmann Link: https://patchwork.freedesktop.org/patch/msgid/20201201103542.2182-19-tzimmermann@suse.de

drm/virtio: align blob resources to page sizes

2020-12-22T12:43:30+00:00

They trigger the BUG_ON() in drm_gem_private_object_init otherwise. Signed-off-by: Chia-I Wu Link: http://patchwork.freedesktop.org/patch/msgid/20201219031959.92932-1-olvaffe@gmail.com Cc: Gurchetan Singh Cc: Gerd Hoffmann Signed-off-by: Gerd Hoffmann

drivers: gpu: drm: virtio: fix dependency of DRM_VIRTIO_GPU on VIRTIO

2020-12-22T12:43:29+00:00

VIRTIO itself has no dependencies and therefore can easily be just select'ed, instead of depending on it. The current depends on causes any others trying to select VIRTIO to fail like this: drivers/gpu/drm/Kconfig:74:error: recursive dependency detected! drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by DRM_VIRTIO_GPU drivers/gpu/drm/virtio/Kconfig:2: symbol DRM_VIRTIO_GPU depends on VIRTIO drivers/virtio/Kconfig:2: symbol VIRTIO is selected by GPIO_VIRTIO drivers/gpio/Kconfig:1618: symbol GPIO_VIRTIO depends on GPIOLIB drivers/gpio/Kconfig:14: symbol GPIOLIB is selected by I2C_MUX_LTC4306 drivers/i2c/muxes/Kconfig:47: symbol I2C_MUX_LTC4306 depends on I2C drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER It seems that having both 'depends on' as well as 'select' on the same symbol sends us into big trouble, and Kconfig can't break up the circular dependency (note that in the tested configuration, neither I2C, FB or DRM are enabled at all). Perhaps we could consider this a bug in Kconfig, but the trouble can easily be circumvented by changing 'depends on' into 'select'. DRM_VIRTIO_GPU also depends on VIRTIO_MENU, so even after this change, that option will only show up if the user already enabled virtio in the config. This change didn't cause any changes in the .config after menuconfig run, so we should be completely safe here. Signed-off-by: Enrico Weigelt, metux IT consult Reviewed-by: Anthoine Bourgeois Link: http://patchwork.freedesktop.org/patch/msgid/20201204131221.2827-1-info@metux.net Signed-off-by: Gerd Hoffmann

drm/virtio: consider dma-fence context when signaling

2020-12-02T10:48:14+00:00

This an incremental refactor towards multiple dma-fence contexts in virtio-gpu. Since all fences are still allocated using &virtio_gpu_fence_driver.context, nothing should break and every processed fence will be signaled. The overall idea is every 3D context can allocate a number of dma-fence contexts. Each dma-fence context refers to it's own timeline. For example, consider the following case where virgl submits commands to the GPU (fence ids 1, 3) and does a metadata query with the CPU (fence id 5). In a different process, gfxstream submits commands to the GPU (fence ids 2, 4). fence_id (&dma_fence.seqno) | 1 2 3 4 5 ----------------------------------|----------- fence_ctx 0 (virgl gpu) | 1 3 fence_ctx 1 (virgl metadata query)| 5 fence_ctx 2 (gfxstream gpu) | 2 4 With multiple fence contexts, we can wait for the metadata query to finish without waiting for the virgl gpu to finish. virgl gpu does not have to wait for gfxstream gpu. The fence id still is the monotonically increasing sequence number, but it's only revelant to the specific dma-fence context. To fully enable this feature, we'll need to: - have each 3d context allocate a number of fence contexts. Not too hard with explicit context initialization on the horizon. - have guest userspace specify fence context when performing ioctls. - tag each fence emitted to the host with the fence context information. virtio_gpu_ctrl_hdr has padding + flags available, so that should be easy. This change goes in the direction specified above, by: - looking up the virtgpu_fence given a fence_id - signalling all prior fences in a given context - signalling current fence v2: fix grammar in comment v3: add r-b tags Reviewed-by: Anthoine Bourgeois Signed-off-by: Gurchetan Singh Link: http://patchwork.freedesktop.org/patch/msgid/20201201021623.619-3-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: rework virtio_fence_signaled

2020-12-02T10:48:14+00:00

virtio_gpu_fence_event_process sets the last_fence_id and subsequently calls dma_fence_signal_locked(..). dma_fence_signal_locked(..) sets DMA_FENCE_FLAG_SIGNALED_BIT, which is actually checked before &dma_fence_ops.(*signaled) is called. The check for last_fence_id is therefore a bit redundant, and it will not be sufficient to check the last_fence_id for multiple synchronization timelines. Remove it. v3: add r-b tags Signed-off-by: Gurchetan Singh Reviewed-by: Anthoine Bourgeois Link: http://patchwork.freedesktop.org/patch/msgid/20201201021623.619-2-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: virtio_{blah} --> virtio_gpu_{blah}

2020-12-02T10:48:14+00:00

virtio_gpu typically uses the prefix virtio_gpu, but there are a few places where the virtio prefix is used. Modify this for consistency. v3: add r-b tags Signed-off-by: Gurchetan Singh Reviewed-by: Anthoine Bourgeois Link: http://patchwork.freedesktop.org/patch/msgid/20201201021623.619-1-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/shmem-helper: Use cached mappings by default

2020-11-24T08:10:21+00:00

SHMEM-buffer backing storage is allocated from system memory; which is typically cachable. The default mode for SHMEM objects is writecombine though. Unify SHMEM semantics by defaulting to cached mappings. The exception is pages imported via dma-buf. DMA memory is usually not cached. DRM drivers that require write-combined mappings set the map_wc flag in struct drm_gem_shmem_object to true. This currently affects lima, panfrost and v3d. The drivers mgag200, udl, virtio and vkms continue to use default shmem mappings. The drivers cirrus and gm12u320 change caching flags. Both used writecombine and now switch over to shmem defaults. Both drivers use SHMEM objects as shadow buffers for internal video memory, so cached mappings will not affect them negatively. v3: * set value of shmem pointer before dereferencing it in __drm_gem_shmem_create() (Dan, kernel test robot) v2: * recreate patch on top of latest SHMEM helpers * update lima, panfrost, v3d to select writecombine (Daniel, Rob) Signed-off-by: Thomas Zimmermann Acked-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20201117133156.26822-2-tzimmermann@suse.de