On 11/17/22 20:08, Lukasz Wiecaszek wrote:
On Thu, Nov 17, 2022 at 12:04:35PM +0300, Dmitry Osipenko wrote:If you'll continue to contribute actively, you'll find things that
Hi,I would like to thank you all for your patience and on the same time say
On 11/17/22 07:58, Lukasz Wiecaszek wrote:
The reason behind that patch is associated with videobuf2 subsystemIf new patch version doesn't contain significant changes and you got
(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.
Signed-off-by: Lukasz Wiecaszek <lukasz.wiecaszek@xxxxxxxxx>
acks/reviews for the previous version, then you should add the given
acked-by and reviewed-by tags to the commit message by yourself.
--
Best regards,
Dmitry
sorry that I still cannot follow the process (although I have read
'submitting patches' chapter).
aren't documented at all. Don't worry about it, usually somebody will
tell you about what's missing. Just apply the new knowledge next time ;)