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