AM3356: Slow Recognition on USB OTG port after wakeup

Hi Miyazaki-san,

Thanks for the update on the previous issues.

Does the delay in resume only happen when the USB Flash driver is attached?

Does the delay only happen when Flash driver is attached to the OTG port, but not the host port?

Does the issue only happen with this particular USB Flash driver, not others?

Can you please ask the customer to provide the console output during the suspend/resume process?

Hi Bin,

I received customer feedback as follows.

> Does the delay in resume only happen when the USB Flash driver is attached?

Yes, as far as customer checked, the delay in resume only happens with USF Flash. This issue does not occur when USB Camera is attached.

> Does the delay only happen when Flash driver is attached to the OTG port, but not the host port?

Regarding Host port of their system, modem-device is attached, therefore, they are not able to confirm if it occurs or not.

> Does the issue only happen with this particular USB Flash driver, not others?

> Can you please ask the customer to provide the console output during the suspend/resume process?

Customer confirmed this behavior happened with other USB Flash (SUNPL Flash). I attached console-log (otg_mem_resume_long.zip) which included Buffalo-Flash-log / USB-Camera-log / SUNPL Flash-log.

I hope those information will help,

Best regards,

Miyazaki

Hi Miyazaki-san,

Thanks for the log, it is helpful.

I will try to to replicate the issue on the EVM then debug it.

Hi Miyazaki-san,

Please ask the customer to apply the following kernel patch.

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index b33ec768404b..cb63a4502691 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4410,7 +4410,7 @@ static int hub_set_address(struct usb_device *udev, int devnum)
        else
                retval = usb_control_msg(udev, usb_sndaddr0pipe(),
                                USB_REQ_SET_ADDRESS, 0, devnum, 0,
-                               NULL, 0, USB_CTRL_SET_TIMEOUT);
+                               NULL, 0, USB_CTRL_SET_TIMEOUT/10);
        if (retval == 0) {
                update_devnum(udev, devnum);
                /* Device now using proper address. */

Hi Bin,

Thanks. I shared this patch with customer. I'd like to wait for their feedback for a while.

Best regards,

Miyazaki

Hello Bin,

Customer tried to apply this kernel patch, however, it did not affect this slow recognition unfortunately.

Best regards,

Miyazaki

Hi Miyazaki-san,

Thanks for the update.

Please revert the patch. I will provide a debug patch in a couple days to collect some information for me to narrow down the issue.

Hi Miyazaki-san,

Please ask the customer to add parameter "usbcore.initial_descriptor_timeout=500" in the U-Boot bootargs to see if it shortens the resume time. 

Hello Bin,

I requested customer to verify this U-boot argument. As the result, customer was able to confirm that the resume-time shows about 3 sec.

Thanks for your strong supporting. However, customer is asking if this resume-time be able to be further shorter, because the resume-time indicates less than 1 sec without USB Flash insertion. Would you think it is possible?

And then, it seems customer would like to avoid modification of U-Boot environment as much as possible. Would you consider that it is possible to change this parameter in kernel driver site?

It will be appreciated if you will share your advice/comments on them.

Best regards,

Miyazaki

Hi Miyazaki-san,

Thanks for the update. I am glad the issue is improved.

The change is to make the USB reset/re-enumeration timeout from 5 sec to 500 ms. I think we can safely change it 100 ms too. This would shorten the resume time by another 1.2 sec. Please ask the customer to test with 100 ms.

If the customer doesn't want to modify U-Boot env, they can use the following equivalent patch too. Please note it changes the timeout from 5 sec to 500 ms. The customer can change it shorter accordingly.

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index b33ec768404b..8a0b580acb42 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -63,7 +63,7 @@ MODULE_PARM_DESC(blinkenlights, "true to cycle leds on hubs");
  * 10 seconds to send reply for the initial 64-byte descriptor request.
  */
 /* define initial 64-byte descriptor request timeout in milliseconds */
-static int initial_descriptor_timeout = USB_CTRL_GET_TIMEOUT;
+static int initial_descriptor_timeout = 500;
 module_param(initial_descriptor_timeout, int, S_IRUGO|S_IWUSR);
 MODULE_PARM_DESC(initial_descriptor_timeout,
                "initial 64-byte descriptor request timeout in milliseconds "

I also recommend the customer to apply the patch I posted on 2/23 above, it also shortens a different timeout from 5 sec to 500 ms. The customer can revise this timeout to 100ms too. The customer's test doesn't trigger this timeout, but I have two different USB3.0 thumb drives which can trigger the timeout in both places, so I recommend the customer to apply this patch too.

Hi Bin,

Thank you for your solution for this.

I have shared your comments with customer. Since I did not receive their feedback yet at this time, I'd like to wait a couple of days.

Best regards,

Miyazaki