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. > In that case the first transaction might not be completed while later > ones are. Or does EHCI make this scenario impossible? The HCD should make it impossible. The ony potential bug I see in this vicinity is one that's unaffected by this change: that the HCD got so far behind that it's dealing with transfers from a whole periodic cycle ago (e.g. 256 or 1024 frames in the past). > 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.) 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. - Dave - 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
