On Wed, 9 May 2007, Laurent Pinchart wrote: > I wasn't aware of those functions. Just to make sure I get this right, am I > right to say that URB buffers should be allocated as contiguous cache > coherent physical memory (using usb_buffer_alloc, which in turns call > dma_alloc_coherent for big DMAable buffers) or as normal memory using > scatter-gather routines ?
I agree with what Dave said. For your purposes, you should use plain old kmalloc or get_free_pages. You don't need cache-coherent buffers or scatter-gather mappings. > I currently allocate big bulk buffers using usb_buffer_alloc, which puts a > lot > of pressure on the memory allocator. Using scatter-gather mappings would > help. However, if I'm not mistaken, the usb_sg_* routines are designed for > synchronous use (with usb_sg_wait), and thus can't be used for streaming > data. Correct. But remember, with streaming URBs you don't need terribly big buffers. Just be sure to submit enough URBs to make up for interrupt latency; the size of each URB's buffer doesn't matter very much. If your pipeline can hold 20-ms worth of data, it should be fine. And that's a generous estimate; 5-ms worth would almost always be enough. > Actually I'm not. I submit a few URBs to get high throughput. Even with > several URBs, memory usage is smaller than with a single payload-sized URB. > > Why do I need to set URB_SHORT_NOT_OK on all but the last URB ? As the actual > payload size isn't known (only the maximum payload size is known), a short > packet can be received at any time. The next URBs will be filled with the > next payload, right ? For streaming payloads it doesn't matter so much. But for example, if you had decided at the start which URB should belong to which payload, then a short packet on an intermediate URB could cause a problem -- all the following URBs would be shifted back to the next payload. Or if you were careless, you might end up with a single URB containing data from two different payloads. If none of that matters then there's no need to use the flag. > > If it doesn't send the extra 0-length packet, then you have to make sure > > that your last URB's length is exactly the right amount to make up a > > maximum-sized payload. > > Otherwise the last URB will be filled with packet from the next payload, > right ? Right. > > If it does send an extra 0-length packet then your last URB needs a larger > > length, so that the 0-length packet will be received properly. > > If the last URB doesn't have a larger length, won't the 0-length packet be > received by the next URB, making the USB stack call the completion handler > with a 0-length URB ? Yes. You would then think it was a 0-length payload. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
