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: Mon, 17 Dec 2018 23:38:47 -0800 [thread overview]
Message-ID: <20181218073847.GA4552@infradead.org> (raw)
In-Reply-To: <CAAFQd5BnZHhNjOc6HKt=YVBVQFCcqN0RxAcfDp3S+gDKRvciqQ@mail.gmail.com>
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.
> 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.
next prev parent reply other threads:[~2018-12-18 7:38 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 [this message]
2018-12-18 9:48 ` Tomasz Figa
2018-12-19 7:51 ` Christoph Hellwig
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=20181218073847.GA4552@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