On Mon, Jul 1, 2013 at 10:48 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 1 Jul 2013, Ming Lei wrote: > The fact that the delay is small doesn't matter -- what's important is > that it will be > 0 whereas now there is no delay between completion > and resubmission (in fact, the resubmission occurs before the > completion ends). Yes, that is the change tasklet is bringing, so looks we need to find a way to distinguish streaming-on from underrun when stream->td_list becomes empty in iso_stream_schedule(). > >> I don't think >> the introduced tasklet delay is a problem for EHCI since per EHCI spec >> the maximum rate at which the host controller will issue interrupts is one >> microframe(125us), which means isochronous transfer completion can be >> reported to CPU with about 125us delay in hardware level. > > Irrelevant. Besides, the delay can be longer than 125 us if another > interrupt is being handled. > >> > Thus, for example, even if the pipeline contains only a single URB, >> > with the current code it will not become empty. But with the new code >> > it will. If the load on the system is too high, the pipeline could >> > empty out even if it normally contains two or more URBs. >> >> Single URB may not work well too when running complete() in hard >> irq context. > > It could work very well indeed, if the interval between URBs was larger > than 1 ms. It is too fragile so that single isoc URB is seldom used, isn't it? Thanks, -- Ming Lei -- 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
