Pushed this one here to drm-misc-next.

Thanks, Christian.

Am 17.11.22 um 18:18 schrieb Lukasz Wiecaszek:

The reason behind that patch is associated with videobuf2 subsystem (or more genrally with v4l2 framework) and user created dma buffers (udmabuf). In some circumstances when dealing with V4L2_MEMORY_DMABUF buffers videobuf2 subsystem wants to use dma_buf_vmap() method on the attached dma buffer. As udmabuf does not have .vmap operation implemented, such dma_buf_vmap() natually fails.

videobuf2_common: __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each videobuf2_common: __prepare_dmabuf: buffer for plane 0 changed videobuf2_common: __prepare_dmabuf: failed to map dmabuf for plane 0 videobuf2_common: __buf_prepare: buffer preparation failed: -14

The patch itself seems to be strighforward. It adds implementation of .vmap and .vunmap methods to 'struct dma_buf_ops udmabuf_ops'. .vmap method itself uses vm_map_ram() to map pages linearly into the kernel virtual address space. .vunmap removes mapping created earlier by .vmap. All locking and 'vmapping counting' is done in dma_buf.c so it seems to be redundant/unnecessary in .vmap/.vunmap.

Reviewed-by: Dmitry Osipenko dmitry.osipenko@collabora.com Acked-by: Christian König christian.koenig@amd.com Signed-off-by: Lukasz Wiecaszek lukasz.wiecaszek@gmail.com

---

v1: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kerne... v2: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kerne... v3: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kerne... v4: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kerne...

v4 -> v5: Added Acked-by and Reviewed-by to the commit message v3 -> v4: Removed line/info 'reported by kernel test robot' v2 -> v3: Added .vunmap to 'struct dma_buf_ops udmabuf_ops' v1 -> v2: Patch prepared and tested against 6.1.0-rc2+

drivers/dma-buf/udmabuf.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)

diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 283816fbd72f..740d6e426ee9 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -13,6 +13,8 @@ #include <linux/slab.h> #include <linux/udmabuf.h> #include <linux/hugetlb.h> +#include <linux/vmalloc.h> +#include <linux/iosys-map.h> static int list_limit = 1024; module_param(list_limit, int, 0644); @@ -60,6 +62,30 @@ static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma) return 0; } +static int vmap_udmabuf(struct dma_buf *buf, struct iosys_map *map) +{

• struct udmabuf *ubuf = buf->priv;
• void *vaddr;
• dma_resv_assert_held(buf->resv);
• vaddr = vm_map_ram(ubuf->pages, ubuf->pagecount, -1);
• if (!vaddr)

• return -EINVAL;
  

• iosys_map_set_vaddr(map, vaddr);
• return 0;

+}

+static void vunmap_udmabuf(struct dma_buf *buf, struct iosys_map *map) +{

• struct udmabuf *ubuf = buf->priv;
• dma_resv_assert_held(buf->resv);
• vm_unmap_ram(map->vaddr, ubuf->pagecount);

+}

• static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, enum dma_data_direction direction) {

@@ -162,6 +188,8 @@ static const struct dma_buf_ops udmabuf_ops = { .unmap_dma_buf = unmap_udmabuf, .release = release_udmabuf, .mmap = mmap_udmabuf,

• .vmap = vmap_udmabuf,
• .vunmap = vunmap_udmabuf, .begin_cpu_access = begin_cpu_udmabuf, .end_cpu_access = end_cpu_udmabuf, };