From: Lukasz Wiecaszek <lukasz.wiecaszek@googlemail.com>
To: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Cc: "Lukasz Wiecaszek" <lukasz.wiecaszek@googlemail.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
"Christian König" <christian.koenig@amd.com>,
linaro-mm-sig@lists.linaro.org, kraxel@redhat.com,
"Sumit Semwal" <sumit.semwal@linaro.org>,
linux-media@vger.kernel.org
Subject: Re: [PATCH] udmabuf: add vmap method to udmabuf_ops
Date: Sat, 12 Nov 2022 07:11:08 +0100 [thread overview]
Message-ID: <20221112061108.GA679753@thinkpad-p72> (raw)
In-Reply-To: <512e97ec-5d5e-4d6a-e547-13ca4036f3d1@collabora.com>
On Fri, Nov 11, 2022 at 03:31:15PM +0300, Dmitry Osipenko wrote:
> On 11/11/22 15:05, Christian König wrote:
> > Adding Dmitry as well.
> >
> > Am 11.11.22 um 12:45 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: [cap-000000003473b2f1] __vb2_queue_alloc: allocated
> >> 3 buffers, 1 plane(s) each
> >> videobuf2_common: [cap-000000003473b2f1] __prepare_dmabuf: buffer for
> >> plane 0 changed
> >> videobuf2_common: [cap-000000003473b2f1] __prepare_dmabuf: failed to
> >> map dmabuf for plane 0
> >> videobuf2_common: [cap-000000003473b2f1] __buf_prepare: buffer
> >> preparation failed: -14
> >>
> >> The patch itself seems to be strighforward.
> >> It adds implementation of .vmap method to 'struct dma_buf_ops
> >> udmabuf_ops'.
> >> .vmap method itself uses vm_map_ram() to map pages linearly
> >> into the kernel virtual address space (only if such mapping
> >> hasn't been created yet).
> >
> > Of hand that sounds sane to me.
> >
> > You should probably mention somewhere in a code comment that the cached
> > vaddr is protected by the reservation lock being taken. That's not
> > necessary obvious to everybody.
> >
> > Apart from that looks good to me.
>
> Adding a comment won't hurt.
>
> We have the dma_resv_assert_held() in dma_buf_vmap() that will help
> spotting a missing lock at runtime by developers. While the
> dmbuf_ops->vmap() shouldn't be ever used directly by importers.
>
> --
> Best regards,
> Dmitry
>
Give me some time guys. I need to prepare patch agains 6.1. And this is
my first time, so now it hurts.
Lukasz
WARNING: multiple messages have this Message-ID (diff)
From: Lukasz Wiecaszek <lukasz.wiecaszek@googlemail.com>
To: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Cc: "Christian König" <christian.koenig@amd.com>,
"Lukasz Wiecaszek" <lukasz.wiecaszek@googlemail.com>,
kraxel@redhat.com, "Sumit Semwal" <sumit.semwal@linaro.org>,
dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org,
linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] udmabuf: add vmap method to udmabuf_ops
Date: Sat, 12 Nov 2022 07:11:08 +0100 [thread overview]
Message-ID: <20221112061108.GA679753@thinkpad-p72> (raw)
In-Reply-To: <512e97ec-5d5e-4d6a-e547-13ca4036f3d1@collabora.com>
On Fri, Nov 11, 2022 at 03:31:15PM +0300, Dmitry Osipenko wrote:
> On 11/11/22 15:05, Christian König wrote:
> > Adding Dmitry as well.
> >
> > Am 11.11.22 um 12:45 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: [cap-000000003473b2f1] __vb2_queue_alloc: allocated
> >> 3 buffers, 1 plane(s) each
> >> videobuf2_common: [cap-000000003473b2f1] __prepare_dmabuf: buffer for
> >> plane 0 changed
> >> videobuf2_common: [cap-000000003473b2f1] __prepare_dmabuf: failed to
> >> map dmabuf for plane 0
> >> videobuf2_common: [cap-000000003473b2f1] __buf_prepare: buffer
> >> preparation failed: -14
> >>
> >> The patch itself seems to be strighforward.
> >> It adds implementation of .vmap method to 'struct dma_buf_ops
> >> udmabuf_ops'.
> >> .vmap method itself uses vm_map_ram() to map pages linearly
> >> into the kernel virtual address space (only if such mapping
> >> hasn't been created yet).
> >
> > Of hand that sounds sane to me.
> >
> > You should probably mention somewhere in a code comment that the cached
> > vaddr is protected by the reservation lock being taken. That's not
> > necessary obvious to everybody.
> >
> > Apart from that looks good to me.
>
> Adding a comment won't hurt.
>
> We have the dma_resv_assert_held() in dma_buf_vmap() that will help
> spotting a missing lock at runtime by developers. While the
> dmbuf_ops->vmap() shouldn't be ever used directly by importers.
>
> --
> Best regards,
> Dmitry
>
Give me some time guys. I need to prepare patch agains 6.1. And this is
my first time, so now it hurts.
Lukasz
next prev parent reply other threads:[~2022-11-13 13:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-11 11:45 [PATCH] udmabuf: add vmap method to udmabuf_ops Lukasz Wiecaszek
2022-11-11 11:45 ` Lukasz Wiecaszek
2022-11-11 12:05 ` Christian König
2022-11-11 12:05 ` Christian König
2022-11-11 12:31 ` Dmitry Osipenko
2022-11-11 12:31 ` Dmitry Osipenko
2022-11-12 6:11 ` Lukasz Wiecaszek [this message]
2022-11-12 6:11 ` Lukasz Wiecaszek
2022-11-11 16:02 ` kernel test robot
2022-11-11 16:02 ` kernel test robot
2022-11-11 19:44 ` kernel test robot
2022-11-11 19:44 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221112061108.GA679753@thinkpad-p72 \
--to=lukasz.wiecaszek@googlemail.com \
--cc=christian.koenig@amd.com \
--cc=dmitry.osipenko@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kraxel@redhat.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=sumit.semwal@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.