On Thursday 16 February 2006 7:10 am, Dima Epshtein wrote: > Hi, > > I found one more minor bug in EHCI driver. > In the file ehci.h struct ehci_iso_stream has the field u8 interval; > > But accordingly with standard bInterval for ISO endpoints can be value > from 1 to 16 > It means that interval in micro-frames can be from 2^(1-1) = 1 to > 2^(16-1). > It obviously more than u8. > > So my test fails when I tried to work with ISO endpoint when > bInterval=8. > > I suggest to change interval field in struct ehci_iso_stream from u8 to > u16
That would be another thing you should submit a patch for then. Though it's worth noting that the physical schedules in use will support a max of 2^10 frames, more often just 2^8 ... and that for fullspeed ISO, periods other than one frame seem to be rare to the point of "never seen in the wild". - Dave > Thanks > Dima > > -----Original Message----- > From: David Brownell [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 15, 2006 8:05 PM > To: [email protected] > Cc: Dima Epshtein > Subject: Re: [linux-usb-devel] EHCI High speed periodic scheduler - ITD > reuse problem > > 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&kid3432&bid#0486&dat1642 > _______________________________________________ > [email protected] > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel > ------------------------------------------------------- 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
