[Sorry for the late follow-up as I've been absent] At Fri, 10 Jul 2009 18:59:23 +0000, James Bottomley wrote: > > 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. Well, the requirement of the non-streaming mmap is rather a historical reason. From the fairly early time, the sound driver provided the mmap of a whole ring buffer since it's practical and efficient for real-time sound processes. But, usually the mmap mode is optional. If it's not supported, apps should fall back to the normal read/write mode. Now, the problem is that we have no way to tell whether the DMA ring-buffer mmap is available or not on each architecture. So, my proposal has basically two meanings: - clarify which arch / platform supports the coherent DMA mapping of a whole ring-buffer - provide the same API to cover the possible archs / platforms In that sense, if a few (or all) PA-RISC platforms don't give the proper coherent mapping that the sound apps require, it's OK. We just drop the flag in the driver as "unsupported", then. So... before going to the detail of PA-RISC implementation, I'd like to know your opinions: whether applying dma_mmap_coherent() to possible archs/platforms is a reasonable solution for such a scenario. [Why not using the standard map->sync procedure is another level of question :) My goal here is to improve the current (partly broken) situation in a minimal effort. The change of mmap procedure would lead to major rewrites of API, and thus has to be discussed more deeply.] Any comments appreciated. thanks, Takashi -- 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
