Hi Alan, Thanks for your information. It really helps a lot! We checked the user-space software which use libusb to communicate to the device. The interrupt transfer was initiate once and re-submitted in the completion callback. The transfer buffer length was initiated to be 2048 !! which actually makes no sense. In high-speed mode, there's no complication for the interrupt transfer data lengths from the device are all less than 1024, which will cause short packet every time. But for full-speed, there's a case that the transfer data length is 64 bytes which exactly is the max packet size of the endpoint. So the host do not know that the data is all transfered, and it just keep issue IN token and the device NAK. We learned that for interrupt transfer the transfer buffer length should be initiated to be the max packet size of the endpoint. And we have fix the issue in that software. Thanks again for your help. Regards Wang Rong On Thu, Jul 4, 2013 at 11:05 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 4 Jul 2013, Rong Wang wrote: > >> Hi Greg, >> >> Thanks for your suggestion. We are trying to move to kernel-3.10. >> >> But I still have a question about EHCI which actually abstracts our question. >> I have noticed Figure 4-14. Host Controller Queue Head Traversal State Machine >> in EHCI spec. >> >> Simplified: >> execute transaction --------------- >> | | >> !Active | | >> | | Active (we encounter >> this case, and it keeps but host controller actually receive data to >> overlay and ACK device) >> \|/ | >> write back qTD | >> | | >> | | >> \|/ | >> follow QH horizontal pointer <-| >> >> The left path is normal case, but we encounter the right path and it >> keeps that state. >> So I wander under which case would the host controller leave Active >> '1' and do not >> write the overlay back to qTD, but actually it receives date and ACK the device. >> and the total bytes to transfer in the overlay actually decrease. >> >> Could you comment on this case? I've not found a clear answer in the spec yet. > > This happens when the qTD contains a buffer that is longer than the > endpoint's maxpacket size. After the first transaction executes, the > Active bit is still set because there is still more data to receive. > > For example, suppose the maxpacket size is 64 bytes and the transfer > size is 100 bytes. The first transaction will receive 64 bytes, and > the Active bit will remain 1. Then the next transaction will receive > the remaining 36 bytes, after which the Active bit will go to 0 and the > overlay will be written back to the qTD. > > 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
