On Tue, 13 Jun 2006, David Brownell wrote: > > 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.
That sounds right. > > 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... Okay. I didn't have any particular hardware in mind. In fact, this question came up while I was thinking about implementing ISO support in dummy-hcd. So it was just a theoretical question. Alan Stern _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
