On Friday 19 May 2006 2:22 pm, Alan Stern wrote: > However it does point out a weak area of the Gadget API. Typically ISO > transfers involve time-sensitive data. That is, if a transfer fails you > prefer to ignore the failure rather than spending time to fix it.
And for ISO, the hardware is supposed to go immediately to the next transfer ... when the controller driver reports such issues to the gadget driver, the gadget driver already knows "it's ISO" and so it would at most feed the fact of an error into some algorithm that's trying to improve data stream robustness. Maybe it'd use one of the feedback mechanisms to trigger transmit of a new key frame. > But the Gadget API doesn't provide any simple way to specify time > limits for ISO submissions. If the gadget driver wants to send 100 > packets at roughly 1-ms intervals, it can't tell the controller driver to > forget about a packet that doesn't complete within its 1-ms window. That's a job for hardware, not software. I think it's why a lot of the full speed ISO devices are hard-wired at 1-msec intervals; they discard the ISO data if it's not been collected, switch to the next packet (double buffered, yes?), and even handle cases like a missed SOF by synthesizing one and updating the frame counter. > If > a transfer request isn't received from the host, all the remaining > packets in the queue will be delayed until the current packet can be sent. > > Or am I misunderstanding something? I think it's just an issue of hardware quirks. If the net2280 driver has that issue, it may need a software workaround. It's easy to see how to do that for periodic transfer rates of N-msec (N integral), but for microframe periods (e.g. one iso packet every other microframe) that's not quite so obvious... - Dave _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
