On Tue, Jul 2, 2013 at 11:12 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 2 Jul 2013, Ming Lei wrote: > >> 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(). > > The difference will be the URB_ISO_ASAP flag. The flag should be set > in the first URB of a new stream. It should not be set in any other > URBs, unless the client driver doesn't care about losing > synchronization when an underrun occurs. So sounds a better name for the flag should be URB_ISO_STREAM_ON, :-) Also looks drivers need fix for the API change. > >> >> > 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? > > Maybe not for isochronous. Interrupt transfers almost always use a > single URB, though, and they don't have any trouble. If interrupt transfer cares the latency, I think the driver should use more than one URB too, but actually most of interrupt usage(hub, hid, status report in communication, ...) doesn't care the latency, but surely both audio and video drivers care the latency. 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
