On Wed, 9 Jan 2008, Karsten Wiese wrote: > Am Montag, 7. Januar 2008 schrieb David Brownell: > > This has some bugfixes for the EHCI driver's ISO transfer scanning > > logic. It was leaving ITDs and SITDs on the schedule too long, for > > a few different reasons, which caused trouble. > > > > (a) Look at all microframes for high speed transfers, not just > > the ones we expect to have finished. This way transfers > > ending mid-frame will complete without needing another IRQ. > > This also minimizes bogus scheduling underruns (e.g. EL2NSYNC). > > > > (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)? In that case the first transaction might not be completed while later ones are. Or does EHCI make this scenario impossible? Wouldn't it be safer to continue scanning until you reach transactions scheduled for the current uframe or later? 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
