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 -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
