On Mon, 21 Jun 2010, David Brownell wrote: > > > but recall my point was that this is just > > > a way to work around USB stacks that have > > > weak support for transfer queues ... > > > > Not just the software stacks -- the hardware as well. > > EHCI and OHCI > > specifically require transfer buffers to be "virtually > > contiguous", > > > Which is a non-issue unless you're trying to > accept buffers in virtual memory. Which is by > no means a requirement associated with sane > support for URB transfer queues... > > > If I queue two separate URBs each of which has > a length of exactly N packets (no ZLP at end), > then the HCD will send 2*N packets, with a > likely small temporal gap after the Nth... > > So the recipient could view that as a single > transfer of 2*N packets, and not care that it > came from two separate transfer buffers... Sure. But what if the first URB's length is somewhere between N-1 and N packets? There's no way to set things up so that the device will see it as a single transfer of length between 2N-1 and 2N packets, unless you engage in some buffer bouncing. And that is because the controller hardware won't allow you to merge the last bit of data from the first URB and the initial bit of data from the second URB into a single packet. Alan Stern -- 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
