On Tue, 11 May 2010, FUJITA Tomonori wrote:
On Tue, 11 May 2010 10:24:40 -0400 Konrad Rzeszutek Wilk konrad.wilk@oracle.com wrote:
Either the data isn't getting written to the buffer correctly or else the buffer isn't getting sent to the device correctly. Can anybody suggest a means of determining which is the case?
I can't say anything about this log that including only DMA addresses. I'm not familiar with how the USB core does DMA stuff. And the USB stack design that the USB core does DMA stuff (allocating, mappings, etc) makes debugging DMA issues really difficult.
The DMA stuff is simple enough in this case. The urb->transfer_buffer address is passed to dma_map_single(), and the DMA address it returns is stored in urb->transfer_dma. Those are the two values printed out by the debugging patch.
Is that address (urb->transfer_dma) the same as 'virt_to_phys(urb->transfer_buffer)' (if not, then SWIOTLB is being utilized) and is the dma_sync_* done on the urb->transfer_dma (to properly sync the data from the SWIOTLB to the transfer_buffer) before you start using the urb->transfer_buffer?
Or calling dma_unmap_single.
Can you tell me all the exact process of DMA that the usb core and the driver do?
1. The audio driver stores data in urb->transfer_buffer.
2. The audio driver calls usb_submit_urb(urb).
3. The USB core does urb->transfer_dma = dma_map_single(controller, urb->transfer_buffer, urb->transfer_buffer_length, DMA_TO_DEVICE);
4. The host controller driver tells the hardware to carry out the data transfer.
5. When the hardware says the transfer is finished, the USB core does dma_unmap_single(controller, urb->transfer_dma, urb->transfer_buffer_length, DMA_TO_DEVICE);
6. The audio driver's completion handler is called: (urb->complete)(urb);
Alan Stern