On Fri, 8 Nov 2013, David Laight wrote: > > The whole idea of TD fragments is exceedingly cloudy. The definition > > doesn't make sense, and the spec doesn't say what the actual hardware > > restrictions are, i.e., what is the underlying reality that the TD > > fragment concept wants to express. > > I think that a TD fragment boundary exists whenever a TRB/dma boundary > lines up with the packet boundary. The spec doesn't say that. > > Even if you do your best to ignore the whole idea, there still appear > > to be certain restrictions you need to obey. In addition to the > > question of where Link TRBs are allowed, you also have to worry about > > TDs whose size isn't a multiple of the Max Burst Payload (MBP) size = > > MaxBurstSize * MaxPacketSize. > > I'm not certain what MaxBurstSize and MaxPacketSize are, but the important > number is the MBP. I'm fairly sure that is the value returned by > GET_MAX_PACKET() - 1024 for USB3 bulk endpoints. GET_MAX_PACKET always returns MaxPacketSize, and for USB-3 bulk endpoints, MaxPacketSize is always 1024. MaxBurstSize can be anything from 1 to 16. > > According to my version of the spec (Rev 1.0, dated 5/21/2010), if a TD > > is larger than the MBP and its length isn't a multiple of the MBP, then > > the last MBP boundary in the TD must also be a TRB boundary. This > > follows from two statements in section 4.11.7.1: > > > > If the TD Transfer Size is an even multiple of the MBP then all > > TD Fragments shall define exact multiples of MBP data bytes. > > If not, then only the last TD Fragment shall define less than > > MBP data (or the Residue) bytes. > > No, that doesn't stop there being only 1 TD fragment. > (I think it means exact multiple of the MBP.) Suppose, for example, the MBP is 1024. If you have a TD with length 1500, and if it had only one fragment, the last (and only) fragment's length would not less than the MBP and it would not be an exact multiple of the MBP. I agree that the text is not as clear as it should be. 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
