On Fri, 7 Sep 2012, Peter Chen wrote: > > > > 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?) The class driver submits packets 5-8, because each time the completion handler runs it prepares 4 iTDs. > 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). Clemens pointed out that this won't work if the delay is too long. 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
