USB transfer_buffer allocations on 64bit systems
in [Kernel]
|
Prev: mfd: Initialise WM831x IRQ masks on chip even if interrupts not in use
Next: INFO: task apache2:7601 blocked for more than 120 seconds.
From: Alan Stern on 11 May 2010 11:00 On Tue, 11 May 2010, Konrad Rzeszutek Wilk 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)' I don't know. We didn't print out the value of virt_to_phys(urb->transfer_buffer). All I can say is that urb->transfer_dma is the value returned by dma_map_single(). > (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? There are no calls to any dma_sync_* routines. Daniel will have to check me on this, but I believe that urb->transfer_buffer is filled before dma_map_single() is called and it isn't touched again until after dma_unmap_single() (which occurs before urb's completion handler is called). Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 11 May 2010 11:10 On Tue, 11 May 2010, FUJITA Tomonori wrote: > On Tue, 11 May 2010 10:24:40 -0400 > Konrad Rzeszutek Wilk <konrad.wilk(a)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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Daniel Mack on 11 May 2010 11:10 On Tue, May 11, 2010 at 10:57:07AM -0400, Alan Stern wrote: > There are no calls to any dma_sync_* routines. Daniel will have to > check me on this, but I believe that urb->transfer_buffer is filled > before dma_map_single() is called and it isn't touched again until > after dma_unmap_single() (which occurs before urb's completion handler > is called). Yes, that's correct. Sorry fot the misleading information I gave. The code doesn't to any weird tricks as it currently stands. It fills the buffer, submits the URB and doesn't touch the buffer contents afterwards. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: FUJITA Tomonori on 11 May 2010 11:40 On Tue, 11 May 2010 11:04:55 -0400 (EDT) Alan Stern <stern(a)rowland.harvard.edu> wrote: > On Tue, 11 May 2010, FUJITA Tomonori wrote: > > > On Tue, 11 May 2010 10:24:40 -0400 > > Konrad Rzeszutek Wilk <konrad.wilk(a)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. How urb->transfer_buffer is allocated? > 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); The mapping error is checked via dma_mapping_error? Even if an mapping error happens, no data corruption happens due to that (needs something like retrying the request)? > 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); The driver does only DMA_TO_DEVICE? Or you see DMA problems only with DMA_TO_DEVICE? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 11 May 2010 12:10
On Wed, 12 May 2010, FUJITA Tomonori wrote: > > > 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. > > How urb->transfer_buffer is allocated? By kmalloc(). Right, Daniel? > > 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); > > The mapping error is checked via dma_mapping_error? Even if an mapping > error happens, no data corruption happens due to that (needs > something like retrying the request)? Yes, we check dma_mapping_error(). If there's an error then the submission fails, and presumably this failure would be logged by the audio driver. > > 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); > > The driver does only DMA_TO_DEVICE? Or you see DMA problems only with > DMA_TO_DEVICE? The particular test that Pedro is running uses audio output only -- he's sending sound data to a speaker and it comes out noisy. But the audio data has to come from somewhere, and I don't remember where. Pedro, does the noise occur only when you're playing sound that comes from a different USB device? What happens if you play sounds that are stored on your hard disk, like an MP3 file? Or what happens if you take the incoming sound data and store it in a disk file, and then later play that file out through the speaker? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |