public inbox for linux-kernel@vger.kernel.org
 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: 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.

  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