On Mon, 24 Jun 2013, Felipe Balbi wrote: > Hi, > > On Mon, Jun 24, 2013 at 05:12:50PM +0200, Sebastian Andrzej Siewior wrote: > > On 06/24/2013 05:04 PM, Felipe Balbi wrote: > > >> - the change violates USB spec(1.1/2.0/3.0) > > > > > > I can't see how this would violate USB spec. USB specifications > > > have no knowledge of scatter-gather. > > > > > > It really doesn't matter how the data gets into the HW's FIFO, as > > > long as it *does* get there. IOW an SG table like below: > > > > > > sg[0].length = 512 sg[1].length = 512 sg[2].length = 20 > > > > > > is no different than: > > > > > > sg[0].length = 502 sg[1].length = 512 sg[2].length = 30 > > > > > > from the USB perspective, all is sees is 1044 bytes being shifted > > > through the data lines. > > > > It is a little. The first USB packet has 512 vs 502 bytes on the wire. > > you wouldn't notice the difference. The DMA engine is the one which > would read the sgtable to figure where the data is scattered, at the end > of the day, SW only knows of a single 1044bytes URB and controller is > required to generate proper USB packets out of that. That simply isn't true. The DMA engine in EHCI, for example, is not capable of constructing a packet out of discontiguous memory buffers. (Unless the discontinuities all occur exactly on page boundaries, but that's not what we're discussing here.) Furthermore, if the HCD doesn't have DMA support then we break the transfer up into multiple URBs, each corresponding to a single SG element. The data in the SG buffers do not get rearranged, so you would inevitably end up with a short packet at the end of one of the intermediate URBs. 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
