On Thu, 16 Apr 2009, Alan Stern wrote: > > I disagree with your interpretation. I believe that you can issue a > > 188 byte SSPLIT even if you know there is another transfer going on, > > and even if you have issued another smaller transfer (less than 188 > > bytes obviously) earlier in that uframe. The TT has a (minimum) 752 > > byte SSPLIT buffer that it uses to buffer transfers up and execute > > when possible. > > Doesn't this contradict your earlier statement that a multi-uframe > transfer has to be scheduled so that its first SSPLIT (and each of the > following 188-byte SSPLITs) occupies an otherwise empty uframe? After > all, a 188-byte transfer that begins in the same uframe as another > smaller transfer will certainly be multi-uframe. To put it another way... Suppose isoc-OUT transfer A has length 50 and its SSPLIT is scheduled in uframe 0, and you want now to schedule isoc-OUT transfer B. If B has length 180, then you're saying it's okay to schedule B's SSPLIT in uframe 0 also, letting the TT buffer the excess 42 output bytes across the uframe boundary. But if B has length 190, then according to what you wrote earlier it's _not_ okay to schedule B's first SSPLIT in uframe 0 (with the second 2-byte SSPLIT in uframe 1), letting the TT buffer the excess 50 output bytes over the uframe boundary. What reason is there for this difference? Don't the two cases appear pretty much the same to the TT? 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
