Linux PARISC architecture development
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Russell King <rmk@arm.linux.org.uk>
Cc: Takashi Iwai <tiwai@suse.de>,
	linux-arch@vger.kernel.org,
	Gerhard Pircher <gerhard_pircher@gmx.net>,
	Parisc List <linux-parisc@vger.kernel.org>
Subject: Re: [PATCH 3/8] parisc: implement dma_mmap_coherent()
Date: Fri, 10 Jul 2009 18:59:23 +0000	[thread overview]
Message-ID: <1247252363.3936.52.camel@mulgrave.site> (raw)
In-Reply-To: <20090710183925.GB1019@flint.arm.linux.org.uk>

On Fri, 2009-07-10 at 19:39 +0100, Russell King wrote:
> On Fri, Jul 10, 2009 at 06:30:50PM +0000, James Bottomley wrote:
> > On Fri, 2009-07-10 at 19:16 +0100, Russell King wrote:
> > > As far as sound DMA goes, it's not about mailboxes.  It's about a circular
> > > buffer which you want the device to DMA from direct to/from the DAC/ADC
> > > and have the application write/read data directly to/from that same
> > > buffer.
> > 
> > But that makes it sound like ordinary streaming DMA from a device to
> > user space ... that's what the dma_map_xx APIs are already designed to
> > handle:  I don't understand why you need coherent memory for this (which
> > can be a scarce resource on some platforms).

> The streaming APIs are inefficient for this.  Consider the overhead of
> having to writeback and invalidate caches at 200KB/s (which is what
> you're requiring ARM to do).  That's far too much CPU overhead.

Um, but streaming APIs are what we use for all block and network I/O
from user space ... we don't see huge performance problems running up to
gigabits.  Even on parisc where we have to flush several times to make
this happen we can get up to several hundred megabytes per second.

> It's much more efficient to use non-cached memory for this on ARM.
> 
> We've been doing this for years and years, it's well proven.
> 
> > Why?  The dma_map_xx API is designed to be zero copy.
> 
> Except with a rather large overhead of repetitive cache handling.

OK, so this is the bit I don't get ... why isn't the streaming a problem
for I/O then, which even on arm wants far more than 200kb/s?

James



  reply	other threads:[~2009-07-10 18:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <s5hprc8n0od.wl%tiwai@suse.de>
     [not found] ` <s5hljmwn0iw.wl%tiwai@suse.de>
2009-07-10 15:11   ` [PATCH 3/8] parisc: implement dma_mmap_coherent() James Bottomley
2009-07-10 18:16     ` Russell King
2009-07-10 18:30       ` James Bottomley
2009-07-10 18:39         ` Russell King
2009-07-10 18:59           ` James Bottomley [this message]
2009-07-17 14:13             ` Takashi Iwai
2009-07-17 19:16               ` James Bottomley
2009-07-19 12:23                 ` Takashi Iwai

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=1247252363.3936.52.camel@mulgrave.site \
    --to=james.bottomley@hansenpartnership.com \
    --cc=gerhard_pircher@gmx.net \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=rmk@arm.linux.org.uk \
    --cc=tiwai@suse.de \
    /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