On Mon, 5 Sep 2005, Franck wrote: > 2005/9/5, Alan Stern <[EMAIL PROTECTED]>: > > On Mon, 5 Sep 2005, Franck wrote: > > > > > > And NAK response to an interrupt transfer definitely _should_ be > > > > retried, > > > > at the next interrupt period. > > > > > > ok so I definetly can't use this feature for interrupt polling and > > > isoc transfer. > > > > I don't understand. How does the feature work, and why can't you use it? > > > > well, the feature allows the hardware to automatically restart a > transaction when the function previously handshaked it with a NAK. If > the function is a hub and the transaction is used to poll its endpoint > 1...the hub will send NAK as long as there's no change on its ports. > Therefore the hardware will be busy to restart the transaction until > there's a change on the hub's ports...That's why I said that I could > not use this feature for interrupt polling.
But _when_ does the hardware restart the transaction? Does it restart right away? Does it try to do all the remaining transactions for this frame and then restart? Does it wait until the next frame? Or does it wait until the next interrupt period (if this is an interrupt transaction)? And if it restarts right away, how many times does it restart? If the device keeps sending NAK, will the hardware continue to restart the transaction until it reaches the end of the frame, without trying any of the other transactions remaining in the frame? (Note that this would violate the USB protocol, making the restart feature pretty useless.) > When you say that I should just keep retrying until transfer completes > or unlinked. Does that mean I should start the next frame with the > NAKed transaction even if there are isoc transactions scheduled for > that frame ? No. You should start the next frame with whatever transaction is appropriate for the beginning of that frame. For instance, if you schedule iso and interrupt transfers before control and bulk, then you should start the next frame with its iso and interrupt transfers, even if a control or bulk transaction was NAKed during this frame. Here's how the UHCI driver works. Each frame has a list of endpoints with transactions scheduled. All the iso and interrupt endpoints come first on the list, followed by all the control endpoints and then all the bulk endpoints. The lists for different frames have different iso and interrupt endpoints, but all frames share the same control and bulk sublist. When a transaction completes successfully or with an error, it is removed from the list. If it fails to complete because the device sent a NAK, the transaction remains on the list. Then the controller will execute the transaction again the next time it goes through the list. If it's an interrupt transaction, that next time won't occur until the next interrupt period. If it's a control or bulk transaction, that next time will occur as soon as the current list is finished if Full Speed Bandwidth Reclamation is turned on (because after reaching the end of the list, the controller goes back to the start of the control endpoints). If FSBR is turned off, that next time will occur in the next frame (because after reaching the end of the list, the controller stops). Alan Stern ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
