mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: "David Xiao" <dxiao@broadcom.com>
Cc: "Russell King - ARM Linux" <linux@arm.linux.org.uk>,
	"Ben Dooks" <ben-linux@fluff.org>,
	"Hugh Dickins" <hugh.dickins@tiscali.co.uk>,
	"Robin Holt" <holt@sgi.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"v4l2_linux" <linux-media@vger.kernel.org>,
	"linux-arm-kernel@lists.arm.linux.org.uk" 
	<linux-arm-kernel@lists.arm.linux.org.uk>
Subject: Re: How to efficiently handle DMA and cache on ARMv7 ? (was "Is get_user_pages() enough to prevent pages from being swapped out ?")
Date: Fri, 7 Aug 2009 09:58:30 +0200	[thread overview]
Message-ID: <200908070958.31322.laurent.pinchart@ideasonboard.com> (raw)
In-Reply-To: <1249624766.32621.61.camel@david-laptop>

On Friday 07 August 2009 07:59:26 David Xiao wrote:
> On Thu, 2009-08-06 at 15:25 -0700, Russell King - ARM Linux wrote:
> > As far as userspace DMA coherency, the only way you could do it with
> > current kernel APIs is by using get_user_pages(), creating a scatterlist
> > from those, and then passing it to dma_map_sg().  While the device has
> > ownership of the SG, userspace must _not_ touch the buffer until after
> > DMA has completed.
> >
> > However, that won't work with ARMv7's speculative prefetching.  I'm
> > afraid with such things, DMA direct into userspace mappings becomes a
> > _lot_ harder, and lets face it, lots of Linux drivers just aren't going
> > to bother supporting this - we can't currently get agreement to have an
> > API to map DMA coherent pages into userspace!
>
> The V7 speculative prefetching will then probably apply to DMA coherency
> issue in general, both kernel and user space DMAs. Could this be
> addressed by inside the dma_unmap_sg/single() calling dma_cache_maint()
> when the direction is DMA_FROM_DEVICE/DMA_BIDIRECTIONAL, to basically
> invalidate the related cache lines in case any filled by prefetching?
> Assuming dma_unmap_sg/single() is called after each DMA operation is
> completed.

Sorry about this, but I'm not sure to understand the speculative prefetching 
cache issue completely.

My understanding is that, even if userspace doesn't touch the DMA buffer while 
DMA is in progress, it could still read from locations close to the buffer, 
resulting in a speculative prefetch of data in the buffer. Those data would 
then end up in the D-cache, and would not be coherent with what the device 
transfers.

If that's correct, how do we avoid the problem in the general case of DMA to 
kernel-allocated buffers ?

Regards,

Laurent Pinchart


  reply	other threads:[~2009-08-07  7:56 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-06 10:08 Laurent Pinchart
2009-08-06 11:46 ` Ben Dooks
2009-08-06 13:06   ` Laurent Pinchart
2009-08-06 18:46     ` David Xiao
2009-08-06 19:16       ` Chetan.Loke
2009-08-06 20:15       ` Jamie Lokier
2009-08-06 22:25       ` Russell King - ARM Linux
2009-08-07  5:59         ` David Xiao
2009-08-07  7:58           ` Laurent Pinchart [this message]
2009-08-07  8:10             ` Russell King - ARM Linux
2009-08-07  9:54               ` Jamie Lokier
2009-08-07  9:59                 ` Russell King - ARM Linux
2009-08-07 12:07                 ` Laurent Desnogues
2009-08-07 13:15                   ` Robin Holt
2009-08-07 19:01                     ` Russell King - ARM Linux
2009-08-07 20:11                       ` Laurent Pinchart
2009-08-07 20:28                         ` Russell King - ARM Linux
2009-08-07 22:25                           ` David Xiao
2009-08-10 13:49                           ` Laurent Pinchart
2009-08-07  8:08           ` Russell King - ARM Linux
2009-08-07 10:23           ` Jamie Lokier
2009-08-07 19:03             ` Russell King - ARM Linux
2009-08-11  9:31           ` Catalin Marinas
2009-08-11 18:23             ` David Xiao
2009-08-07  7:48         ` Laurent Pinchart
2009-08-25 12:53         ` Steven Walter
2009-08-25 22:02           ` David Xiao
2009-08-25 23:17             ` Laurent Pinchart
2009-08-26 17:22               ` David Xiao
2009-09-01 13:31                 ` Russell King - ARM Linux
2009-09-01 18:08                   ` David Xiao
2009-09-01 13:28           ` Russell King - ARM Linux
2009-09-01 13:43             ` Laurent Pinchart
2009-09-01 14:18               ` Russell King - ARM Linux
2009-09-01 16:53                 ` Hugh Dickins
2009-09-02 15:10               ` Imre Deak
2009-09-03  7:31                 ` Imre Deak
2009-09-03  8:36                 ` Russell King - ARM Linux
2009-09-08 13:05                   ` Steven Walter
2009-08-07  7:29       ` Laurent Pinchart
2009-08-07  8:12         ` Matthieu CASTET
2009-08-07 10:13           ` How to efficiently handle DMA and cache on ARMv7 ? (was " Is " Laurent Pinchart

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=200908070958.31322.laurent.pinchart@ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=ben-linux@fluff.org \
    --cc=dxiao@broadcom.com \
    --cc=holt@sgi.com \
    --cc=hugh.dickins@tiscali.co.uk \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    /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

all inboxes | Powered by JetHome®