Am Friday 30 January 2009 19:17:59 schrieb Sarah Sharp: > On Fri, Jan 30, 2009 at 12:14:11PM +0100, Oliver Neukum wrote: > > Am Thursday 29 January 2009 17:30:27 schrieb David Vrabel: > > > I don't see where the complexity is. The HCD simply fills the > > > hardware's s-g list structures based on the s-g list in the URB. > > > > > > Obviously, none of the existing HCDs can support s-g lists in this > > > manner and should continue to only accept URBs without s-g lists. > > > > Meaning that drivers that want to take advantage of this would need > > to test for this ability and have different code paths for it. > > I don't think drivers need to change. The USB core's sg_init and > sg_wait function behaviors would change, but their API would not. Where > do you see the need for drivers to change? We do not want to limit burst support to storage and hence need generic support for scatter/gather. At a minimum the faster network adaptors, video and usbfs (think eg. 16GB of photos over PTP) need to support it. > > Therefore I would prefer chained URBs despite their size. For HCDs > > whose maximum chain length is exceeded usbcore could walk the chain > > and submit them iteratively. > > What do you mean by "chain length"? Something to do with URB anchors? Very early in the development of Linux USB URBs had a chaining facility. That led me to the idea that we could put URBs on a linked list and submit the whole "chain" by submitting the first URB only. HCDs that can do scatter/gather can process the whole chain, for others usbcore can do a simple interation. Regards Oliver -- 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
