At Fri, 15 Jan 2010 17:50:49 +1100, Benjamin Herrenschmidt wrote: > > On Fri, 2010-01-15 at 07:43 +0100, Takashi Iwai wrote: > > > > > It -might- be worth looking at adding code to the USB stack to > > propagate > > > the parent device dma_ops down to USB devices... hard to tell. > > > > Or we may simply need to drop the mmap support on such > > architectures... > > Nah, that would suck since that includes x86 nowadays :-) Ah, no, I meant about non-coherent architectures that can't use vmalloc pages as the intermediate buffer. Dropping mmap for x86 would be a big regression ;) > I think you probably need to separate the struct device * used for DMA > (it could be default be the same as the "main" struct device tho or it > could default to NULL which means no mmap support). > > USB could (if not already) provide an accessor to obtain the HC's struct > device for such mappings. We'll have to discuss that with Alan Stern I > suppose. > > The USB Audio or similar drivers could then use that accessors to fill > up Alsa's dma_device field to replace the "default". The situation of usb-audio is, unfortunately, a bit more complex because the driver needs a continuous ring-buffer. The packet data are copied from that intermediate buffer on demand. This isn't efficient, but the continuous ring-buffer is demanded by the current API design exported as mmap. thanks, Takashi
