Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1337065

Re: [PATCH v6 4/5] videobuf2-dc: Let drivers specify DMA attrs

From Tomasz Figa <tfiga@chromium.org>
Newsgroups linux.kernel
Subject Re: [PATCH v6 4/5] videobuf2-dc: Let drivers specify DMA attrs
Date 2016-02-18 07:00 +0100
Message-ID <r3pN8-Yw-15@gated-at.bofh.it> (permalink)
References <qPOBH-5zs-3@gated-at.bofh.it> <qPOBI-5zs-15@gated-at.bofh.it> <r3dLZ-10I-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hi Hans,

On Thu, Feb 18, 2016 at 2:00 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> Hi Doug,
>
> Is there any reason to think that different planes will need different
> DMA attrs? I ask because this patch series of mine:
>
> http://www.spinics.net/lists/linux-media/msg97522.html
>
> does away with allocating allocation contexts (struct vb2_dc_conf).
>
> For dma_attr this would mean that struct dma_attrs would probably be implemented
> as a struct dma_attrs pointer in the vb2_queue struct once I rebase that patch series
> on top of this patch. In other words, the same dma_attrs struct would be used for all
> planes.

I could think of some format consisting of video and metadata planes
(such as V4L2_PIX_FMT_S5C_UYVY_JPG) and some hypothetical hardware,
which generates the metadata in a way that requires patching in
.buf_finish(). In this case, we can allocate video plane without
kernel mapping, but for metadata plane kernel mapping is necessary to
do the patching.

However the above is only a hypothetical "what if" of mine, since
personally I haven't seen such case yet. Our real use case is
allocating raw video planes without kernel mapping, while keeping
kernel mapping available for encoded bitstream, which needs some extra
patching. The reason for disabling kernel mapping is that vmalloc
space can be easily exhausted when processing high resolution video
with long buffer queues (e.g. high resolution H264 decode/encode).

>
> Second question: would specifying dma_attrs also make sense for videobuf2-dma-sg.c?

For our particular use case, probably not, because I don't see kernel
mapping being implicitly created at videobuf2-dma-sg level for
allocated MMAP buffers. AFAICT only if vb2_plane_vaddr() or respective
DMA-BUF op is called then the mapping is created, which is unavoidable
because the caller apparently needs it for something.

Best regards,
Tomasz

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

Re: [PATCH v6 4/5] videobuf2-dc: Let drivers specify DMA attrs Hans Verkuil <hverkuil@xs4all.nl> - 2016-02-17 18:10 +0100
  Re: [PATCH v6 4/5] videobuf2-dc: Let drivers specify DMA attrs Doug Anderson <dianders@chromium.org> - 2016-02-17 18:30 +0100
  Re: [PATCH v6 4/5] videobuf2-dc: Let drivers specify DMA attrs Tomasz Figa <tfiga@chromium.org> - 2016-02-18 07:00 +0100

csiph-web