I'm writing about this because Matt Dharm ran across some problems a few months back and posted a message about it on the usb-storage development list, and my own delving into the details of scatter-gather operations have yielded some new information.
Most of the scatter-gather buffers passed to usb-storage will always be page-aligned. That's true of everything coming through the block layer (hence from the sd driver) and everything using bounce buffers in st and sg. However, there are circumstances in which st and sg will perform direct I/O -- passing s-g lists that refer to buffers in userspace. For the st driver these circumstances are not unusual. All that's required is for direct I/O support to be enabled in the driver (which it is by default) and that the host adapter is not marked as having one of those old 24-bit ISA DMA masks. With sg it's a bit rarer because the user program has to explicitly request a direct I/O transfer. Anyway, the s-g buffer is located in userspace, and it can be wherever the user program puts it. It doesn't have to be aligned on any sort of boundary at all. I don't know whether this causes problems for regular host adapters, but it does for usb-storage. Usb-storage uses David Brownell's scatter-gather library for s-g data transfers. This library constructs a set of URBs (one for each entry in the s-g list) and submits the whole thing to the HCD at once, thus minimizing inter-packet overhead. Unfortunately, this means that when a buffer isn't aligned properly, the first URB in the series may have a transfer length that isn't a multiple of the maxpacket value. The URB will necessarily end with a short packet, and the device will interpret this as indicating a premature end of the entire data transfer. This doesn't sound like a particularly easy problem to solve. The simplest solution would be to copy unaligned data to a single large bounce buffer, thereby negating the advantages of direct I/O. Another possibility would be to have lots of little bounce buffers to take care of the "splices" -- the places where a maxpacket-sized transfer would have to span two adjacent s-g entries. That would involve less data movement but would require setting up twice as many URBs. For the moment this isn't a very urgent problem, but it's something we should think about solving in the future. If anyone has any better ideas about how to fix it, I'd be pleased to hear them. Alan Stern ------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
