Re: USB transfer_buffer allocations on 64bit systems

[Daniel Mack <daniel@caiaq.de>]

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