On Fri, 13 Dec 2013, vichy wrote: > hi > > 2013/12/2 Alan Stern <st...@rowland.harvard.edu>: > > On Sun, 1 Dec 2013, vichy wrote: > > > >> hi Alan: > >> > >> 2013/12/1 Alan Stern <st...@rowland.harvard.edu>: > >> > On Fri, 29 Nov 2013, vichy wrote: > >> > > >> >> hi all: > >> >> My connection like below > >> >> ehci --> high speed hub -> full speed device > >> >> > >> >> I have some questions about period scheduling. > >> >> 1. when creating qh for full speed device, why we set EHCI_TUNE_RL_TT. > >> > > >> > Are you asking why EHCI_TUNE_RL_TT is equal to 0? I don't know -- it > >> > looks like a mistake. Do you find that changing it to 3 makes any > >> > difference? > >> Yes, when I change EHCI_TUNE_RL_TT as not 0. > >> The transaction can keep going. > > > > But if EHCI_TUNE_RL_TT is 0, the transfer doesn't work? > No. the transaction will stop since device return Nak. > I copy the usb traffic log for your reference.
The device did not return NAK. The NAK was sent by the high-speed hub the device was attached to. > usually device will not return NAK in setup token. but in my case, it did. When EHCI_TUNE_RL_TT is set to 0, the controller should never stop retrying the transfer. That's what 0 means here -- 3 means stop (temporarily) after 3 attempts, but 0 means never stop. This sounds like a bug in your EHCI hardware. What type of controller are you using? Anyway, I don't mind changing EHCI_TUNE_RL_TT to 3. Would you like to submit a patch? 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
