On Thursday 10 January 2008, Alan Stern wrote: > On Wed, 9 Jan 2008, David Brownell wrote: > > > On Wednesday 09 January 2008, Alan Stern wrote: > > > 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. > > > > Nope; scheduler bug. There's an explicit requirement for a gap > > between "now" and when the first new transfer can be added. Should > > that requirement be expressed wrong, or not implemented correctly, > > that'd be a bug. > > Hmmm... Where is this requirement made explicit?
See iso_stream_schedule() where it calculates the next uframe a new stream could start. Although, hmm, that doesn't quite kick in on except on initial schedules. Which might indicate there actually *is* an open bug there. > There are comments > about what should happen when URB_ISO_ASAP is set, but what about when > it isn't set? The only scheduling policy supported by EHCI (and OHCI) is ASAP. If it's not set, both drivers act as if it's set. - 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
