On Wed, 23 May 2012, Felipe Balbi wrote: > On Wed, May 23, 2012 at 10:52:14AM -0400, Alan Stern wrote: > > > generates xfernotready > > > to SW, gadget is not ready to send data now. Host is still sending IN > > > token and receives 0 byte packet. Gadget becomes ready after an > > > *undefined* time. Now it does not have track of micro frame number. > > > > The Gadget API has a weakness in that it does not give drivers a way to > > specify which microframe a particular isochronous packet should belong > > to. > > > > So what happens if an IN packet from the host gets corrupted or lost? > > Does all the following isochronous data get shifted back by one > > interval, or does some of the data get skipped? The Gadget API doesn't > > say. > > yeah this is something which needs to be sorted out, indeed. But this > will only work if controllers give us a reliable way for gadget drivers > to ask which uframe we are now, which isn't always the case. Then how do > we solve that part ? When an isochronous stream first starts up, the initial uframe doesn't matter; in fact, it's generally meaningless. The uframe value matters only when subsequent requests are submitted. The most common requirements will be: 1: The data for the new request should start at the slot following the data in the previous request, even if that slot has already expired. 2: The data for the new request should start at the next available slot, even if that means skipping some slots between the previous request and this one. In the host API, drivers indicate that they want option 2 by setting the URB_ISO_ASAP flag. (Although, as far as I know, the only HCD which currently implements this correctly is uhci-hcd.) The only situation I can think of where a driver might want to specify an actual uframe value for a transfer would be when it is trying to synchronize somehow concurrent transfers over multiple endpoints. But there are other, better ways of doing that. Therefore it might make sense to add an iso_asap flag to struct usb_request. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
