[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAFQd5AT3ixnbZRm3TOjoWrk2UNH0bXqgR+Z8wyjMhr0xHtSOg@mail.gmail.com>
Date: Tue, 18 Dec 2018 18:48:03 +0900
From: Tomasz Figa <tfiga@...omium.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: Laurent Pinchart <laurent.pinchart@...asonboard.com>,
"Matwey V. Kornilov" <matwey@....msu.ru>,
Linux Media Mailing List <linux-media@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"Matwey V. Kornilov" <matwey.kornilov@...il.com>,
Alan Stern <stern@...land.harvard.edu>,
Ezequiel Garcia <ezequiel@...labora.com>, hdegoede@...hat.com,
Hans Verkuil <hverkuil@...all.nl>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
rostedt@...dmis.org, mingo@...hat.com,
Mike Isely <isely@...ox.com>,
Bhumika Goyal <bhumirks@...il.com>,
Colin King <colin.king@...onical.com>,
Kieran Bingham <kieran.bingham@...asonboard.com>,
keiichiw@...omium.org
Subject: Re: [PATCH v5 2/2] media: usb: pwc: Don't use coherent DMA buffers
for ISO transfer
On Tue, Dec 18, 2018 at 4:38 PM Christoph Hellwig <hch@...radead.org> wrote:
>
> On Tue, Dec 18, 2018 at 04:22:43PM +0900, Tomasz Figa wrote:
> > It kind of limits the usability of this API, since it enforces
> > contiguous allocations even for big sizes even for devices behind
> > IOMMU (contrary to the case when DMA_ATTR_NON_CONSISTENT is not set),
> > but given that it's just a temporary solution for devices like these
> > USB cameras, I guess that's fine.
>
> The problem is that you can't have flexibility and simplicity at the
> same time. Once you use kernel virtual address remapping you need to
> be prepared to have multiple segments.
>
> So as I said you can call dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT
> in a loop with a suitably small chunk size, then stuff the results into
> a scatterlist and map that again for the device share with if you don't
> want a single contigous region. You just have to either deal with
> non-contigous access from the kernel or use vmap and the right vmap
> cache flushing helpers.
The point is that you didn't have to do this small chunk loop without
DMA_ATTR_NON_CONSISTENT, so it's at least inconsistent now and not
sure why it could be better than just a loop of alloc_page().
>
> > Note that in V4L2 we use the DMA API extensively, so that we don't
> > need to embed any device-specific or integration-specific knowledge in
> > the framework. Right now we're using dma_alloc_attrs() with
> > driver-provided attrs [1], but current driver never request
> > non-consistent memory. We're however thinking about making it possible
> > to allocate non-consistent memory. What would you suggest for this?
> >
> > [1] https://elixir.bootlin.com/linux/v4.20-rc7/source/drivers/media/common/videobuf2/videobuf2-dma-contig.c#L139
>
> I would advice against new non-consistent users until this series
> goes through, mostly because dma_cache_sync is such an amazing bad
> API. Otherwise things will just work at the allocation side, you'll
> just need to be careful to transfer ownership between the cpu and
> the device(s) carefully using the dma_sync_* APIs.
Just to clarify, the actual code isn't very likely to surface any time
soon. so I assume it would be after this series lands.
We will however need an API that can transparently handle both cases
of contiguous (without IOMMU) and page-by-page allocations (with
IOMMU) behind the scenes, like the current dma_alloc_attrs() without
DMA_ATTR_NON_CONSISTENT.
Best regards,
Tomasz
Powered by blists - more mailing lists