Re: [alsa-devel] USB transfer_buffer allocations on 64bit systems
On Mon, 2010-05-10 at 11:50 +0900, FUJITA Tomonori wrote:
On Fri, 7 May 2010 10:51:10 -0400 (EDT) Alan Stern stern@rowland.harvard.edu wrote:
On Fri, 7 May 2010, Daniel Mack wrote:
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.
At one point we tried an experiment, printing out the buffer and DMA addresses. I don't recall seeing anything obviously wrong, but if an IOMMU was in use then that might not mean anything. Is it possible that the IOMMU mappings sometimes get messed up for addresses above 4 GB?
You mean that an IOMMU could allocate an address above 4GB wrongly? If so, IIRC, all the IOMMU implementations use dev->dma_mask and dev->coherent_dma_mask properly. And the DMA address space of the majority of IOMMUs are limited less than 4GB.
The Intel IOMMU code will use dev->dma_mask and dev->coherent_dma_mask properly. It is not limited to 4GiB, but it will tend to give virtual DMA addresses below 4GiB even when a device is capable of more; it'll only give out higher addresses when the address space below 4GiB is exhausted.
participants (1)
-
David Woodhouse