On Fri, Jan 30, 2009 at 07:31:23PM +0100, Oliver Neukum wrote: > 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. Ok, sure, I see your point. I was testing on MSDs, so my world is a bit narrow right now. :) > > > 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. I think I understand... You're suggesting one URB per buffer for non-sg-capable drivers. And all URBs that are part of one transfer (which may include multiple packets sent in a burst) are chained together, correct? Would drivers that currently use usb_sg_init() still use that function, or will they have to be re-written to create chained URBs? If they continue to use usb_sg_*, what should that function do with that scatter gather list if the HCD supports scatter gather? Turn it into a chained URB with one URB per sg list entry? That way HCDs would just have to deal with buffers in chained URBs, rather than chained URBs and single URBs with scatter gather lists in them. Does usb_sg_init() need to create even more URBs when the sg list entry exceeds the wMaxPacketSize buffer length limit? I think if the USB core is submitting a chained URB to a scatter gather capable HCD, it doesn't need to honor the wMaxPacketSize buffer length limit. This rule is new to me, so I may be confused. Sarah Sharp -- 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
