On Thu, Apr 16, 2009 at 2:29 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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. I believe this is ok per USB spec, and this is how the current code should behave. > 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? I believe this is ok per USB spec, but the current code does not do this simply because it was easier to calculate availability by putting a transfer larger than 1 uframe into an empty uframe. I do not think that the USB spec mandates putting a > 1uframe transfer into its own empty starting uframe (although for isoc OUT you do have to SSPLIT-begin with 188 bytes, but I believe you can do this even if there is another SSPLIT in that same uframe). -- 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
