On Thu, 1 Oct 2009, Sarah Sharp wrote: > Does the EHCI driver respect the isochronous scheduling threshold that the > hardware reports? Depends what you mean. As I recall, the scheduling threshold is defined mainly for use in unlinking -- and ehci-hcd doesn't really support unlinking isochronous transfers at all. > I see that the driver sets ehci->i_thresh to the number of microframes that the > host controller may cache (plus 2 if the host controller reports a number of > microframes instead of just one frame), but the driver doesn't seem to do > anything with i_thresh. Right. > I see several places in iso_stream_schedule() in ehci-sched.c that use > SCHEDULE_SLOP. I don't really understand the case where the stream is already > being used, If the stream is already in use then new iTDs can be scheduled for any frame right down to the currently active frame. It's not a big deal if they turn out to be scheduled too soon; since they're isochronous we expect that now and then some of them won't get transferred properly. > but the case where the driver is scheduling for the first time > says: > > /* need to schedule; when's the next (u)frame we could start? > * this is bigger than ehci->i_thresh allows; scheduling itself > * isn't free, the slop should handle reasonably slow cpus. it > * can also help high bandwidth if the dma and irq loads don't > * jump until after the queue is primed. > */ > start = SCHEDULE_SLOP * 8 + (now & ~0x07); > > SCHEDULE_SLOP is defined as 10 frames. So is the EHCI driver attempting to > schedule the isoc transfer at least 10 frames in the future? Yes. Or rather, 10 frames from the start of the current frame, which is somewhat less than 10 ms (but more than 9 ms) in the future. > Does it do this > in all cases? Not sure what you're asking. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
