Alan Stern wrote: > [For new readers, the context is a discussion on how to allow large > transfers in usbfs without having to break them up into small pieces. > Forcing libusb to follow the many-small-pieces approach doesn't work > well when an IN transfer ends in the middle with a short packet.] > > On Tue, 23 Jun 2009, Tim Roberts wrote: > >> For reference, the Windows solution is to lock the user-mode pages and >> map them into kernel space, so it uses up address space but not memory. > > Mapping the pages into kernel space is irrelevant, isn't it? What > matters is the DMA address used by the host controller or IOMMU, not > the virtual address. > >> Windows limits a single EHCI bulk transfer to about 3 MB. Interrupt >> endpoints don't have an artificial limit; you can do whatever will fit >> before it squeals. > > I imagine users would be a lot happier with a 3 MB limit than a 16 KB > limit. But don't there have to be alignment restrictions for it to > work? I've not seen the rest of this discussion. We have a plan to allow larger buffers by using a scatter-gather list for the transfer. Each user-space page mapped into kernel space will be a separate sg list element. This should allow zero-copy with no alignment restrictions. You would need to add support for urbs with scatter-gather lists to ehci-hcd. This may be tricky. whci-hcd, for example, required the use of bounce buffers for certain sg lists whose elements were neither multiples of a page nor multiples of wMaxPacketSize. However, such sg lists are not common and would not occur with transfers from usbfs. (This reminds me, I must post all this whci-hcd scatter-gather code...) David -- David Vrabel, Senior Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
