All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Tomasz Figa <tfiga@chromium.org>
Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Ricardo Ribalda <ribalda@chromium.org>,
	Christoph Hellwig <hch@lst.de>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv2 8/8] videobuf2: handle non-contiguous DMA allocations
Date: Wed, 7 Jul 2021 22:29:25 +0900	[thread overview]
Message-ID: <YOWsNa0Zaf9UuGWH@google.com> (raw)
In-Reply-To: <CAAFQd5BB6JghdgGf9SjAWYuZFsZaAeU11rV1a1xrwws=w7j7_w@mail.gmail.com>

On (21/07/07 21:48), Tomasz Figa wrote:
> > [..]
> > > static void *vb2_dc_vaddr(struct vb2_buffer *vb, void *buf_priv)
> > > {
> > >         struct vb2_dc_buf *buf = buf_priv;
> > >
> > >         if (buf->vaddr)
> > >                 return buf->vaddr;
> > >
> > >         if (buf->db_attach) {
> > >                 struct dma_buf_map map;
> > >
> > >                 if (!dma_buf_vmap(buf->db_attach->dmabuf, &map))
> > >                         buf->vaddr = map.vaddr;
> > >
> > >                 return buf->vaddr;
> > >         }
> > >
> > >         if (!buf->coherent_mem)
> > >                 buf->vaddr = dma_vmap_noncontiguous(buf->dev, buf->size,
> > >                                                     buf->dma_sgt);
> > >         return buf->vaddr;
> > > }
> > >
> > > And in vb2_dc_alloc functions set vaddr for !DMA_ATTR_NO_KERNEL_MAPPING
> > > in both coherent and non-coherent. So that we probably can have less
> > > branches when ->vaddr is NULL for one type of allocations, and is not
> > > NULL for another.
> 
> I'd prefer if it stayed as is. This opportunistic mapping as in the
> current revision is quite nice, because most of the drivers don't
> bother to set DMA_ATTR_NO_KERNEL_MAPPING even if they don't need the
> kernel mapping. Also, even if the driver itself doesn't need the
> kernel mapping, we can still create one on demand if the DMA-buf
> importer demands it from us.

[..]

> > > static int vb2_dc_alloc_coherent(struct vb2_dc_buf *buf)
> > > {
> > >         struct vb2_queue *q = buf->vb->vb2_queue;
> > >
> > >         buf->cookie = dma_alloc_attrs(buf->dev,
> > >                                       buf->size,
> > >                                       &buf->dma_addr,
> > >                                       GFP_KERNEL | q->gfp_flags,
> > >                                       buf->attrs);
> > >         if (!buf->cookie)
> > >                 return -ENOMEM;
> > >
> > >         if (q->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING)
> > >                 return 0;
> > >
> > >         buf->vaddr = buf->cookie;
> > >         return 0;
> > > }
> > >
> > > static int vb2_dc_alloc_non_coherent(struct vb2_dc_buf *buf)
> > > {
> > >         struct vb2_queue *q = buf->vb->vb2_queue;
> > >
> > >         buf->dma_sgt = dma_alloc_noncontiguous(buf->dev,
> > >                                                buf->size,
> > >                                                buf->dma_dir,
> > >                                                GFP_KERNEL | q->gfp_flags,
> > >                                                buf->attrs);
> > >         if (!buf->dma_sgt)
> > >                 return -ENOMEM;
> > >
> > >         if (q->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING)
> > >                 return 0;
> > >
> > >         buf->vaddr = dma_vmap_noncontiguous(buf->dev, buf->size, buf->dma_sgt);
> > >         if (!buf->vaddr) {
> > >                 dma_free_noncontiguous(buf->dev, buf->size,
> > >                                        buf->dma_sgt, buf->dma_addr);
> > >                 return -ENOMEM;
> > >         }
> > >         return 0;
> > > }
> >
> > I guess this should address the case when
> >
> > "after allocating the buffer, the buffer is exported as a dma_buf and
> > another device calls dma_buf_ops vb2_dc_dmabuf_ops_vmap, which in turn
> > calls dma_buf_map_set_vaddr(map, buf->vaddr); with a NULL buf->vaddr"
> 
> Sorry, I fail to get what this is about. Where does this quote come from?

Bottom half of https://lore.kernel.org/lkml/10a0903a-e295-5cba-683a-1eb89a0804ed@xs4all.nl/

  reply	other threads:[~2021-07-07 13:29 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-27 13:13 [PATCHv2 0/8] videobuf2: support new noncontiguous DMA API Sergey Senozhatsky
2021-04-27 13:13 ` [PATCHv2 1/8] videobuf2: rework vb2_mem_ops API Sergey Senozhatsky
2021-04-27 13:13 ` [PATCHv2 2/8] videobuf2: inverse buffer cache_hints flags Sergey Senozhatsky
2021-04-27 13:13 ` [PATCHv2 3/8] videobuf2: split buffer cache_hints initialisation Sergey Senozhatsky
2021-04-27 13:13 ` [PATCHv2 4/8] videobuf2: move cache_hints handling to allocators Sergey Senozhatsky
2021-04-27 13:13 ` [PATCHv2 5/8] videobuf2: add V4L2_MEMORY_FLAG_NON_COHERENT flag Sergey Senozhatsky
2021-04-27 13:13 ` [PATCHv2 6/8] videobuf2: add queue memory coherency parameter Sergey Senozhatsky
2021-04-27 13:13 ` [PATCHv2 7/8] videobuf2: handle V4L2_MEMORY_FLAG_NON_COHERENT flag Sergey Senozhatsky
2021-05-01  3:48   ` Sergey Senozhatsky
2021-06-03 11:32   ` Hans Verkuil
2021-06-17  1:46     ` Sergey Senozhatsky
2021-04-27 13:13 ` [PATCHv2 8/8] videobuf2: handle non-contiguous DMA allocations Sergey Senozhatsky
2021-04-28  6:14   ` Christoph Hellwig
2021-06-03 11:59   ` Hans Verkuil
2021-06-17  7:56     ` Sergey Senozhatsky
2021-06-17  8:01       ` Christoph Hellwig
2021-06-17  8:30         ` Tomasz Figa
2021-06-17  8:52           ` Christoph Hellwig
2021-06-17  9:40             ` Tomasz Figa
2021-06-17 10:06               ` Christoph Hellwig
2021-06-18  3:21                 ` Tomasz Figa
2021-06-18  4:25                   ` Christoph Hellwig
2021-06-18  4:44                     ` Tomasz Figa
2021-06-22  7:33                       ` Christoph Hellwig
2021-07-07 12:42                         ` Tomasz Figa
2021-06-25  3:10       ` Sergey Senozhatsky
2021-07-07 12:48         ` Tomasz Figa
2021-07-07 13:29           ` Sergey Senozhatsky [this message]
2021-07-07 14:10             ` Tomasz Figa
2021-07-09  7:20               ` Sergey Senozhatsky
2021-06-17  7:56     ` Sergey Senozhatsky

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=YOWsNa0Zaf9UuGWH@google.com \
    --to=senozhatsky@chromium.org \
    --cc=hch@lst.de \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=ribalda@chromium.org \
    --cc=tfiga@chromium.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.