> > Here's the problem we face: The class driver submits packets 1, 2, 3, > and 4. They get sent properly, but the completion interrupt is > delayed. As a result, the class driver's completion handler doesn't > get called until too late; the frames for packets 5 - 44 have already > expired. The data that should have been sent during those frames is > lost. > > But the class driver doesn't know this, so when the completion handler > does get called, it submits packets 5, 6, 7, and 8. They end up > getting sent in frames 45, 46, 47, and 48. This means the data is now > out of synchronization by 40 frames. > > That's the problem I want to solve. > Can I understand this problem like below:
It is OUT ISO transfer, at each completion handler, it prepares 4 iTDs for 4 packets. When the above problem occurs, the class driver will submit packet from 5 - 48, and the controller driver will prepare 44 iTDs. (or the class driver still submits packet 5-8?) If the feedback is supported, the device will know host sends data slowly, it will give speed up feedback information after it receives packet 5 or other packets depends on its interval at descriptor. At this information, it can tell the host to increase the packet size, then the transaction length and transaction numbers at iTD can be increased(Assume it was not maximum). > There's an equivalent problem for data flowing into the host. In this > case, the URB that should have been submitted for frame 5 would receive > data that the device sent during frame 45. (Whether this data contains > the signals for frame 5 or for frame 45 would depend on the device; the > host can't do anything about it.) > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
