On Fri, May 07, 2010 at 11:47:37AM +0200, Clemens Ladisch wrote: > 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. Gnaa, you're right. I _thought_ my code does it the way I described, but what I wrote is how I _wanted_ to do it, not how it's currently done. I have a plan to change this in the future. So unfortunately, that doesn't explain it either. Sorry for the noise. Daniel -- 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
