On Wed, 28 Mar 2007 11:25:54 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> > That is, when the application manages DMA adressing? The driver "should" > > provide both the DMA and regular address, since not every underlying > > controller wil use the DMA address for all transfers. > > That's not quite true. The driver is obliged to provide a regular address > if the controller doesn't use DMA, but it isn't obliged if the controller > does use DMA. And in fact it frequently happens with usb-storage; the > underlying SCSI drivers provide a scatter-gather list with page addresses > that are suitable for DMA but may not lie in kernel-accessible memory. Right. What's more, I found that the transfer_buffer may not even be NULL in such cases. The pre-allocation of buffers and passing DMA address up and down the stack caused a number of complications, which neither network stack (w/ skbuff) nor block stack (w/ request) experience. For one thing, conceptually, upper level driver has to query the DMA bits. We hid this check inside the allocation helper, but it's still there. Another complication is the special-casing of transfers to the root hub. Since both network and block I/O are high performance subsystems, I always regarded all performance arguments for usb_buffer_alloc as rubbish. The poor granularity of DMA mapping is real, but it's a different issue. The usbmon just brought the issues to the forefront, that's all. -- Pete ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
