From: Christoph Hellwig <hch@infradead.org>
To: Tomasz Figa <tfiga@chromium.org>
Cc: Christoph Hellwig <hch@infradead.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
"Matwey V. Kornilov" <matwey@sai.msu.ru>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"Matwey V. Kornilov" <matwey.kornilov@gmail.com>,
Alan Stern <stern@rowland.harvard.edu>,
Ezequiel Garcia <ezequiel@collabora.com>,
hdegoede@redhat.com, Hans Verkuil <hverkuil@xs4all.nl>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
rostedt@goodmis.org, mingo@redhat.com,
Mike Isely <isely@pobox.com>, Bhumika Goyal <bhumirks@gmail.com>,
Colin King <colin.king@canonical.com>,
Kieran Bingham <kieran.bingham@ideasonboard.com>,
keiichiw@chromium.org
Subject: Re: [PATCH v5 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer
Date: Tue, 18 Dec 2018 23:51:50 -0800 [thread overview]
Message-ID: <20181219075150.GA26656@infradead.org> (raw)
In-Reply-To: <CAAFQd5AT3ixnbZRm3TOjoWrk2UNH0bXqgR+Z8wyjMhr0xHtSOg@mail.gmail.com>
On Tue, Dec 18, 2018 at 06:48:03PM +0900, Tomasz Figa wrote:
> > 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().
You have to do it if you want to map the addresses for a second device.
> > 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.
Is the use case to then share the memory between multiples devices
or just for a single device? The latter case is generally easy, the
former is rather more painful.
next prev parent reply other threads:[~2018-12-19 7:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-21 17:06 [PATCH v5 0/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer Matwey V. Kornilov
2018-08-21 17:06 ` [PATCH v5 1/2] media: usb: pwc: Introduce TRACE_EVENTs for pwc_isoc_handler() Matwey V. Kornilov
2018-08-21 19:49 ` Steven Rostedt
2018-08-21 17:06 ` [PATCH v5 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer Matwey V. Kornilov
2018-08-28 7:17 ` Matwey V. Kornilov
2018-09-11 18:58 ` Matwey V. Kornilov
2018-09-19 16:12 ` Ezequiel Garcia
2018-10-10 21:13 ` Matwey V. Kornilov
2018-10-30 22:00 ` Laurent Pinchart
2018-10-31 5:38 ` Christoph Hellwig
2018-12-07 15:25 ` Christoph Hellwig
2018-12-12 8:57 ` Tomasz Figa
2018-12-12 9:09 ` Christoph Hellwig
2018-12-12 9:34 ` Tomasz Figa
2018-12-12 13:54 ` Christoph Hellwig
2018-12-13 3:13 ` Tomasz Figa
2018-12-13 14:03 ` Christoph Hellwig
2018-12-14 3:12 ` Tomasz Figa
2018-12-14 12:36 ` Christoph Hellwig
2018-12-18 7:22 ` Tomasz Figa
2018-12-18 7:38 ` Christoph Hellwig
2018-12-18 9:48 ` Tomasz Figa
2018-12-19 7:51 ` Christoph Hellwig [this message]
2018-12-19 8:18 ` Tomasz Figa
2018-12-19 14:51 ` Christoph Hellwig
2018-12-20 3:23 ` Tomasz Figa
2018-12-21 8:13 ` Christoph Hellwig
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=20181219075150.GA26656@infradead.org \
--to=hch@infradead.org \
--cc=bhumirks@gmail.com \
--cc=colin.king@canonical.com \
--cc=ezequiel@collabora.com \
--cc=hdegoede@redhat.com \
--cc=hverkuil@xs4all.nl \
--cc=isely@pobox.com \
--cc=keiichiw@chromium.org \
--cc=kieran.bingham@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=matwey.kornilov@gmail.com \
--cc=matwey@sai.msu.ru \
--cc=mchehab@kernel.org \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=stern@rowland.harvard.edu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox