On Wed, 9 Jan 2008, David Brownell wrote: > On Wednesday 09 January 2008, Alan Stern wrote: > > > > > > (b) When we encounter an ISO transfer (either speed, but this > > > > hits mostly at full speed) that's not yet been completed, > > > > immediately stop scanning; we've caught up to the hardware, > > > > no matter what other indications might say. > > > > Is this known to be correct? What if an ISO transfer gets added to the > > schedule just a little too late (after the starting frame has ended)? > > That would be called a scheduler bug.
Maybe. Or maybe it's just an overrun. Although we don't include support for it at the moment, I can easily imagine that some applications will need certain Iso packets to be scheduled in certain frames or uframes. This will mean that in some circumstances the HCD might be forced to schedule a packet for a frame without knowing whether or not the controller has already progressed too far. If it has, the result is an underrun. > > Wouldn't it be safer to continue scanning until you reach transactions > > scheduled for the current uframe or later? > > Put it this way: (b) has already been confirmed to fix some bugs > that prevented a microphone-equipped fullspeed webcam from working. > (Well, in conjunction with another fix; but that's silicon-specific > and not related to this issue.) Stopping at an incomplete transaction will turn out to be a bug the first time an underrun is encountered. Neither that packet nor any later ones would ever be returned. > And scanning for "current" had its own issues ... like the problems > fixed by (a). The previous scanning logic was trying to be a bit > too clever; and needlessly so. This doesn't need to be very clever. Just keep scanning until you reach a transaction which is incomplete _and_ is scheduled for >= T, where T is the (u)frame index as of when the scanning began. T doesn't have to be exactly equal to "current". Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
