Re: some question about period scheduleing
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. usually device will not return NAK in setup token. but in my case, it did. Thanks for your kind help, attachment: Device.Nak.png
Re: some question about period scheduleing
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
Re: some question about period scheduleing
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? isn't it possible the full speed device return NAK during transaction? Of course it is possible. If so, why we use EHCI_TUNE_RL_TT default as 0? Like I said above, I don't know -- it looks like a mistake. 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
Re: some question about period scheduleing
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? isn't it possible the full speed device return NAK during transaction? Of course it is possible. that mean once it react with NAK, the host will stop below transaction. The host stops the transaction temporarily. It will restart the transaction later. See section 4.9.1 in the EHCI spec. How could we make sure device never react with NAK? There is no way to do that. 2. I attach my mon log for your reference. there is one thing I am curious why below message 'E' mean in bulk/interrupt? I have checked Document/usb/usbmon.txt but get nothing. E means the preceding submission failed. d8c32600 190047566 E Bi:1:006:2 -19 0 d8c32980 190062351 C Bi:1:006:2 -107 0 d8c32980 190062363 S Bi:1:006:2 -115 1025 d8c32980 190072803 E Bi:1:006:2 -19 0 For example, this E means the submission on the line above was unsuccessful. The error code -19 is -ENODEV, which means the device has been disconnected. This is described in Documentation/usb/usbmon.txt: - Event Type. This type refers to the format of the event, not URB type. Available types are: S - submission, C - callback, E - submission error. 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
Re: some question about period scheduleing
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. isn't it possible the full speed device return NAK during transaction? Of course it is possible. If so, why we use EHCI_TUNE_RL_TT default as 0? that mean once it react with NAK, the host will stop below transaction. The host stops the transaction temporarily. It will restart the transaction later. See section 4.9.1 in the EHCI spec. I find what you mentioned. How could we make sure device never react with NAK? There is no way to do that. 2. I attach my mon log for your reference. there is one thing I am curious why below message 'E' mean in bulk/interrupt? I have checked Document/usb/usbmon.txt but get nothing. E means the preceding submission failed. d8c32600 190047566 E Bi:1:006:2 -19 0 d8c32980 190062351 C Bi:1:006:2 -107 0 d8c32980 190062363 S Bi:1:006:2 -115 1025 d8c32980 190072803 E Bi:1:006:2 -19 0 For example, this E means the submission on the line above was unsuccessful. The error code -19 is -ENODEV, which means the device has been disconnected. This is described in Documentation/usb/usbmon.txt: - Event Type. This type refers to the format of the event, not URB type. Available types are: S - submission, C - callback, E - submission error. Thanks for your help -- 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
