From: Arnd Bergmann <arnd@arndb.de>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Daniel Vetter <daniel@ffwll.ch>,
	"Semwal, Sumit" <sumit.semwal@ti.com>,
	linux@arm.linux.org.uk, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
	linux-mm@kvack.org, linux-media@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
Date: Tue, 20 Dec 2011 15:36:49 +0000	[thread overview]
Message-ID: <201112201536.49754.arnd@arndb.de> (raw)
In-Reply-To: <20111220090306.GO3677@valkosipuli.localdomain>
On Tuesday 20 December 2011, Sakari Ailus wrote:
> (I'm jumping into the discussion in the middle, and might miss something
> that has already been talked about. I still hope what I'm about to say is
> relevant. :-))
It certainly is relevant.
> In subsystems such as V4L2 where drivers deal with such large buffers, the
> buffers stay mapped all the time. The user explicitly gives the control of
> the buffers to the driver and eventually gets them back. This is already
> part of those APIs, whether they're using dma_buf or not. The user could
> have, and often has, the same buffers mapped elsewhere.
Do you normally use streaming (dma_{map,sync,unmap}_*) or consistent
(dma_{alloc,free}_*) mappings for this then?
> When it comes to passing these buffers between different hardware devices,
> either V4L2 or not, the user might not want to perform extra cache flush
> when the buffer memory itself is not being touched by the CPU in the process
> at all. I'd consider it impossible for the driver to know how the user space
> intends to user the buffer.
The easiest solution to this problem would be to only allow consistent mappings
to be shared using the dma_buf mechanism. That means we never have to flush.
If you don't need the CPU to touch the buffer, that would not have any cost
at all, we could even have no kernel mapping at all instead of an uncached
mapping on ARM.
> Flushing the cache is quite expensive: typically it's the best to flush the
> whole data cache when one needs to flush buffers. The V4L2 DQBUF and QBUF
> IOCTLs already have flags to suggest special cache handling for buffers.
[sidenote: whether it makes sense to flush individual cache lines or the entire
cache is a decision best left to the architectures. On systems with larger
caches than on ARM, e.g. 64MB instead of 512KB, you really want to keep
the cache intact.]
	Arnd
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply	other threads:[~2011-12-20 15:37 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-02  8:57 [RFC v2 0/2] Introduce DMA buffer sharing mechanism Sumit Semwal
2011-12-02  8:57 ` [RFC v2 1/2] dma-buf: Introduce dma " Sumit Semwal
2011-12-02 17:11   ` Konrad Rzeszutek Wilk
2011-12-05  9:48     ` Semwal, Sumit
2011-12-05 17:18   ` Arnd Bergmann
2011-12-05 18:55     ` Daniel Vetter
2011-12-05 19:29       ` Arnd Bergmann
2011-12-05 20:58         ` Daniel Vetter
2011-12-05 22:04           ` Arnd Bergmann
2011-12-05 22:33             ` Daniel Vetter
2011-12-05 20:46     ` Rob Clark
2011-12-05 21:23       ` Daniel Vetter
2011-12-05 22:11         ` Rob Clark
2011-12-05 22:33           ` Daniel Vetter
2011-12-06 13:16           ` Arnd Bergmann
2011-12-06 15:28             ` Daniel Vetter
2011-12-07 13:27           ` Semwal, Sumit
2011-12-07 13:40             ` Arnd Bergmann
2011-12-08 21:44               ` [Linaro-mm-sig] " Daniel Vetter
2011-12-09 14:13                 ` Arnd Bergmann
2011-12-09 14:24                   ` Alan Cox
2011-12-10  4:01                     ` Daniel Vetter
2011-12-12 16:48                       ` Arnd Bergmann
2011-12-19  6:16                         ` Semwal, Sumit
2011-12-20 15:41                           ` Arnd Bergmann
2011-12-20 16:41                             ` Rob Clark
2011-12-20 17:14                               ` Daniel Vetter
2011-12-21 17:27                                 ` Arnd Bergmann
2011-12-21 19:04                                   ` Daniel Vetter
2011-12-23 10:00                                   ` Semwal, Sumit
2011-12-23 17:10                                     ` Rob Clark
2011-12-20  9:03                   ` Sakari Ailus
2011-12-20 15:36                     ` Arnd Bergmann [this message]
2012-01-01 20:53                       ` Sakari Ailus
2012-01-01 23:12                         ` Rob Clark
2011-12-13 13:33                 ` Hans Verkuil
2011-12-05 22:09       ` Arnd Bergmann
2011-12-05 22:15         ` Rob Clark
2011-12-05 22:35         ` Rob Clark
2011-12-07  6:35     ` Semwal, Sumit
2011-12-07 10:11       ` Arnd Bergmann
2011-12-07 11:02         ` Semwal, Sumit
2011-12-07 11:34           ` Arnd Bergmann
2011-12-09 22:50     ` [Linaro-mm-sig] " Robert Morell
2011-12-10 11:13       ` Mauro Carvalho Chehab
2011-12-12 22:44         ` Robert Morell
2011-12-13 15:10           ` Arnd Bergmann
2011-12-20  2:05             ` Robert Morell
2011-12-20 14:29               ` Anca Emanuel
2012-01-09  6:20   ` InKi Dae
2012-01-09  8:10     ` Daniel Vetter
2012-01-09  8:11       ` [Linaro-mm-sig] " Dave Airlie
2012-01-09 10:10       ` InKi Dae
2012-01-09 10:27         ` Daniel Vetter
2012-01-09 12:06           ` InKi Dae
2012-01-09 16:02             ` Daniel Vetter
2012-01-09 15:17         ` Rob Clark
2012-01-10  1:34           ` InKi Dae
2012-01-10  2:14             ` Rob Clark
2012-01-10  6:09               ` Semwal, Sumit
2012-01-10  7:28                 ` InKi Dae
2012-01-10  9:19                   ` InKi Dae
2012-01-11  1:08               ` InKi Dae
2011-12-02  8:57 ` [RFC v2 2/2] dma-buf: Documentation for buffer sharing framework Sumit Semwal
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=201112201536.49754.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@arm.linux.org.uk \
    --cc=sakari.ailus@iki.fi \
    --cc=sumit.semwal@ti.com \
    /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).