> > that doesn't matter; we don't get an interrupt when a ring segment is > > crossed. Instead we set the interrupt-on-completion flag on the last > > TRB of the TD, not on any earlier fragment or link TRB. > > That's because you don't worry about handling URBs which require too > many TRBs (i.e., more than are available). You just add more ring > segments. Instead, you could re-use segments on the fly. > > For example, suppose you have only two ring segments and you get an URB > which requires enough TRBs to fill up four segments. You could fill in > the first two segments worth, and get an interrupt when the controller > traverses the Link TRB between them. At that point you store the third > set of TRBs in the first segment, which is now vacant. Similarly, when > the second Link TRB is traversed, you fill in the fourth set of TRBs. That isn't going to work. It might work for very long TD, but for very fragmented ones the interrupt rate would be stupid. In any case you'd definitely need enough ring segments for the TRB that describe a single 'max packet size' block. > > Finally, it's interesting to note that the USB mass storage driver is > > using scatter gather lists just fine without the driver following the TD > > fragment rules. Or at least no one has reported any issues. I wonder > > why it works? > > I'd guess this is because the hardware is actually a lot more flexible > than the "No Link TRBs in the middle of a TD fragment" rule. With the hardware I have (Intel i7 Sandy bridge) Link TRB cannot be placed at arbitrary boundaries. I don't know whether the actual restriction is only to packet boundaries. I don't have a USB3 monitor and it would also require a more contrived test than I've been doing. > The whole idea of TD fragments makes no sense to begin with. What > point is there in grouping packets into MaxBurst-sized collections? It probably saved a few logic gates somewhere, either that or it is a bug in some hardware implementation that got documented in the spec instead of being fixed :-) David -- 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
