Daniel Mack wrote: > The problem is again (summarized): > > On 64bit machines, with 4GB or more, the allocated buffers for USB > transfers might be beyond the 32bit boundary. In this case, the IOMMU > should take care and install DMA bounce buffer to copy over the buffer > before the transfer actually happens. The problem is, however, that this > copy mechanism takes place when the URB with its associated buffer is > submitted, not when the EHCI will actually do the transfer. > > In the particular case of audio drivers, though, the contents of the > buffers are likely to change after the submission. What we do here > is that we map the audio stream buffers which are used by ALSA to > the output URBs, so they're filled asychronously. Once the buffer is > actually sent out on the bus, it is believed to contain proper audio > date. If it doesn't, that's due to too tight audio timing or other > problems. This breaks once buffers are magically bounced in the > background. At least the audio class and ua101 drivers don't do this and fill the buffers before they are submitted. > So - long story short: these audio buffers need to be DMA coherent. Does the USB API actually guarantee that all controllers use DMA, i.e., that the buffers can be filled after submission? Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
