[alsa-devel] USB transfer_buffer allocations on 64bit systems
stern at rowland.harvard.edu
Tue May 11 17:04:55 CEST 2010
On Tue, 11 May 2010, FUJITA Tomonori wrote:
> On Tue, 11 May 2010 10:24:40 -0400
> Konrad Rzeszutek Wilk <konrad.wilk at 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,
4. The host controller driver tells the hardware to carry out the data
5. When the hardware says the transfer is finished, the USB core does
6. The audio driver's completion handler is called:
More information about the Alsa-devel