> "After completing one URB, the next one can be > automatically submitted. This is especially useful for ISO transfers: > You only have read/write the data from/to the buffers in the completion > handler, the continuous streaming itself is transparently done by the > URB-machinery." > > Ok, it *can* be automatically resubmitted, but how?
Usually through linking urb->next fields in a ring. > "Usually, to reduce restart time, the completion handler is called > AFTER the URB re-submission." > > Ok, but under what circumstances is it resubmitted? I think that "usually ... AFTER " is some kind of UHCI-ism, FWIW. Since ISO (like INTR) transfers are "periodic", the normal case is that they're resubmitted ... because they're linked in a ring. > "For ISO there are two startup behaviors: Specified start_frame or ASAP. > For ASAP set USB_ISO_ASAP in transfer_flags." > > Ok -- seems to say that ASAP will send the urb at the first opportunity > and ~ASAP will try to send the urb in the frame specified by the > start_frame field. Make sense. Except that if you look at the mechanism for specifying a start frame, it seems a bit insufficient. Frame counters roll over, but drivers don't know their range. And there's a limit to how far in the future transfers can be scheduled, which is not visible to drivers. ASAP is the only behavior that's really workable with today's API. > "For isochronous endpoints, subsequent submitting of URBs to the same > endpoint with the ASAP flag result in a seamless ISO streaming." > > What does 'seamless streaming' mean? Does this mean urbs with the ASAP > flag are automatically resubmitted? Not clear. Good question. Since these URBs don't stay scheduled, there can easily be situations where the bandwidth that should be "reserved" for such periodic transfers isn't really unavailable ... "seamless" in that context seems like bad technical marketing. :) > "Exception: The execution cannot be scheduled later than 900 frames from > the 'now'-time. The same applies to INT transfers, but here the seamless > continuation is independent of the transfer flags (implicitly ASAP)." > > Lost me here. If the ASAP flag is set then I'm not using scheduling, > right? All URBs are scheduled in some sense. Periodic URBs must be scheduled, else their bandwidth guarantees can't be met. > This 900 frame limit must apply to urbs where ASAP is *not* set > and I'm using the start_frame field, right? 900 frames is absolutely a UHCI-ism. OHCI can schedule up to 2^16 frames in the future, and EHCI schedules over a 2^N period, 1K by default but maybe as small as 256. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
