On Mon, 5 Sep 2005, Franck wrote: > 2005/9/1, Alan Stern <[EMAIL PROTECTED]>: > > On Thu, 1 Sep 2005, Franck wrote: > > > > > Hi, > > > > > > I'm trying to write a host controller driver for a Arc hardware. I > > > need to know how nak pid should be handled ? Hardware can > > > automatically manage them, that means it automatically retry the > > > naked transaction. But since setup packet must not be "NAKed" or hub > > > endpoint #1 returns nak pid when no events happen on its port, I don't > > > think I can use this feature. > > > > Sure you can. The hardware should be smart enough to recognize that a NAK > > response to a SETUP packet is an error, so it won't retry the transaction. > > Not sure the hardware is clever enough. If the hardware quality is the > same level as the datasheet's one then it wont't be smart enough !
I can't help you much with the datasheet. :-) However, recognizing that NAK after IN is legal and NAK after SETUP is illegal doesn't require much intelligence. > > 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? > > > But if I do it manually, what should I > > > do when receiving a NAK ? Should I retry the transaction forever ? > > > > Yes. Until someone unlinks the URB. > > but if the NAKed transaction lasts more than a frame ? What do you mean? A transaction can never last more than a frame. The longest possible full-speed transaction is a 1023-byte ISO transfer, and that takes less than 1 ms. The longest possible bulk/interrupt/control transaction is 64 bytes, which is considerably shorter. Perhaps you mean "What if the device keeps NAKing for longer than a millisecond?" That's okay; devices are allowed to NAK for several seconds, sometimes even longer. You should just keep retrying until the transfer completes or is unlinked. 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
