Does the EHCI driver respect the isochronous scheduling threshold that the hardware reports? 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. 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, 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? Does it do this in all cases? Sarah Sharp -- 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
