> Ok, I've been working all day trying to get ISO support working in my > USB ADSL modem ethernet driver. I'm having difficulty understanding how > the whole ISO submit, resubmit, ring, etc., stuff is supposed to happen. > So, I have a few questions:
Good timing. I'm wondering _why_ it's done the way the OHCI and UHCI drivers do. I suppose I could go check the list archives. > Should I manually set the ->next field > of each to point to the other? That's one way. And set the USB_ISO_ASAP flag. I don't think the explicit scheduling model is usable, since drivers can't know whether it's OK to, for one example, schedule 3000 frames into the future. (OHCI allows it, UHCI and EHCI don't... some EHCI configs won't even schedule 300 frames ahead.) Alternatively, submit them both, then manually resubmit each one in its completion handler. They should then be queued after each other. (That's what I'm assuming folk will do with the EHCI driver, at least for now.) > When I submit the urb(s), since they are a "ring" - do I just submit the > first one, or do I submit both? Both. Think of it as queuing two ISO URBs and then using the ring as just a way to hide the resubmit (and potential error ...) in the completion handler. > Can someone explain the logic in the OHCI driver's sohci_return_urb > routine for iso urbs. Why does it only resubmit an urb if that urb is > part of a ring? UHCI drivers have the same logic, as I recall ... I think the reasoning is along the lines of "broken ring means unlink". Note that OHCI and UHCI also ignore the transfer interval, assuming it's once per frame, but that's not what the USB spec says to do. (EHCI pays attention to that period.) Net result is that ISO scheduling is on the probabalistic side ... while the USB spec says it's supposed to be "guaranteed" (like INTR transfers). > What advantage(s) does setting up the ->next pointers give me over just > resubmitting the urb(s) from my completion handler? Setting urb->next is equivalent to manual resubmit, except that some internal memory free/realloc can be avoided and some other updates can be avoided. The same effect could be had if completion functions returned boolean values saying whether to resubmit, with a pure "queue after the currently scheduled ISO transfers" model. I've wondered why there's even a special descriptor for queued ISO requests. There's no real need for it, since each transfer could live in its own URB, with a standard URB-level queuing model. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
