On Mon, 13 Apr 2009, Alan Stern wrote: > > The tt_available function should (with the -1 removed) only schedule a > > multi-uframe isoc transfer starting in an empty uframe, > > Why? What's wrong with scheduling a multi-uframe isoc transfer to > begin in a partially-occupied uframe? Never mind; I went back to the specs and did some rereading... First of all, IN transfers can never have more than one SSPLIT in any case. Secondly, interrupt transfers never have more than one SSPLIT. Which leaves only isoc OUT. Both the USB and EHCI specs say (although you have to look pretty closely to see it) that if an isoc OUT SSPLIT is scheduled for both uframes N and N+1, then in uframe N it must be scheduled for 188 bytes. Ergo, it has to occupy the entire uframe. (By the way, this is a stronger requirement than saying that transfers larger than 188 bytes have to start at the beginning of a uframe. It also rules out the possibility of allowing a small transfer to occupy parts of two successive uframes.) On the other hand, I still don't see how this patch would fix the bug as originally reported. Also, I still haven't satisfied myself that the scheduler code is entirely correct -- and there hasn't been enough free time to go through it carefully. At least one loose end doesn't seem to have been mentioned anywhere: The USB spec clearly states that periodic split transactions must be scheduled so as not to exceed the relevant time limits on both the full/low-speed bus _and_ the high-speed bus. AFAICT, ehci-sched.c doesn't calculate the bandwidth required on the high-speed bus for split transactions. 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
