linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Fri, 14 Dec 2018 04:36:24 -0800	[thread overview]
Message-ID: <20181214123624.GA5824@infradead.org> (raw)
In-Reply-To: <CAAFQd5BudF84jVaiy7KwevzBZnfYUZggDK=4W=g+Znf5VJjHsQ@mail.gmail.com>

On Fri, Dec 14, 2018 at 12:12:38PM +0900, Tomasz Figa wrote:
> > If the buffer always is physically contiguous, as it is in the currently
> > posted series, we can always map it with a single dma_map_single call
> > (if the hardware can handle that in a single segment is a different
> > question, but out of scope here).
> 
> Are you sure the buffer is always physically contiguous? At least the
> ARM IOMMU dma_ops [1] and the DMA-IOMMU dma_ops [2] will simply
> allocate pages without any continuity guarantees and remap the pages
> into a contiguous kernel VA (unless DMA_ATTR_NO_KERNEL_MAPPING is
> given, which makes them return an opaque cookie instead of the kernel
> VA).
> 
> [1] http://git.infradead.org/users/hch/misc.git/blob/2dbb028e4a3017e1b71a6ae3828a3548545eba24:/arch/arm/mm/dma-mapping.c#l1291
> [2] http://git.infradead.org/users/hch/misc.git/blob/2dbb028e4a3017e1b71a6ae3828a3548545eba24:/drivers/iommu/dma-iommu.c#l450

We never end up in this allocator for the new DMA_ATTR_NON_CONSISTENT
case, and that is intentional.

  reply	other threads:[~2018-12-14 12:36 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 [this message]
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
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=20181214123624.GA5824@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;
as well as URLs for NNTP newsgroup(s).