On Tuesday 14 February 2006 10:56 pm, Dima Epshtein wrote: > > Frame X: -> itd7 -> itd6 -> itd5 -> itd4 -> itd3 -> itd2 -> > itd1 -> itd0 -> NULL > Frame X+1: -> itd9 -> itd8 -> NULL > > So itd0 will be sent on uframe 0 of Frame X, itd1 on uframe 1 of Frame > X, itd8 on uframe 0 of Frame X+1, itd9 on uframe 1 of Frame X+1, etc. > > Now assume itd0 was sent, so function itd_complete was called and itd0 > will moved to stream->free_list, > but itd1 still point to itd0 by hw_next field of struct ehci_itd
A workaround is of course not to submit urbs that consume only parts of a microframe ... e.g. one urb for all of frame X, or for several consecutive frames. That's pretty much what most drivers "upgraded" from full speed ISO support are now doing, which is probably why this issue hasn't been reported before. > 1. Don't move ehci_itd structure to stream->free_list during > itd_complete function immediately, move all ehci_itd structures > linked to Frame X list only when HW will start to process Frame X+1. That sounds like the best sort of solution. It doesn't need to be "when processing X+1", but can just be "the next time an ITD is allocated for that endpoint after frame X completes". - Dave ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
