> But I think that there are actually different applications for real queuing
> and using the next-stuff:
They're both "real" queuing though ... just at different levels:
> 1) Transfering data as fast as possible, with no turnaround time -> queuing
Queueing at the HC. That's what QUEUE_BULK is for. This
is a performance optimization -- very desirable, but optional
because driver correctness can't depend on it.
> 3) Execution of a pre-determined sequence ("program") of unspecified and
> possibly mixed URB-types without user intervention -> next-pointer
Queuing above the HCD ... and outside the device driver.
> 2) Automatic streaming without any user code (mainly ISO) -> next-pointer
That's still the case I have problems with. The scheduling model seems
oddly different from the other periodic transfer type (interrupt), and it
seems like maybe the motivation is to support multi-buffering. (So for
example one video frame can be processed while another is filling.)
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
