USB Host Port Suspend/Resume Hot-Plugging Issue

[marcelziswiler]

This issue concerns the i.MX 8M Mini as e.g. found on the Toradex Verdin iMX8M Mini computer/system on module (CoM/SoM) and NXP BSP 5.4.70_2.3.5. While current mainline linux-next seems to exhibit the same issue I was unable to test any later NXP BSP (would require us first migrating to such later downstream).

We have a customer with a custom Verdin carrier board that does neither use a USB type-c port (e.g. as found on the 8MMINILPD4-EVK) nor a built-in USB hub (e.g. as found on Dahlia or the Verdin Development Board).

If a USB type-a socket is designed in (e.g. where USB2_DN/DP from the i.MX 8M Mini SoC go straight to such receptacle without anything else in-between) the USB host port only works if a device is plugged in during boot. If however one plugs in a device later or unplugs/replugs a device there is absolutely no reaction whatsoever.

After enabling CONFIG_DYNAMIC_DEBUG and observing what is going on upon un-plugging a device using dyndbg="file drivers/usb/* +p" I noticed the following:

[ 25.296391] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
[ 25.301933] ci_hdrc ci_hdrc.1: GetStatus port:1 status 1c00101a 14 ACK POWER sig=se0 OC PEC CSC
[ 25.310797] usb usb2-port1: status 0108, change 0003, 12 Mb/s
[ 25.316577] usb 2-1: USB disconnect, device number 2
[ 25.321572] usb 2-1: unregistering device
[ 25.325618] usb 2-1: unregistering interface 2-1:1.0
[ 25.356567] usb 2-1: usb_disable_device nuking all URBs
[ 25.504125] usb usb2-port1: debounce total 100ms stable 100ms status 0x108
[ 25.511074] hub 2-0:1.0: hub_suspend
[ 25.514717] usb usb2: bus auto-suspend, wakeup 1
[ 25.519389] ci_hdrc ci_hdrc.1: suspend root hub
[ 25.524576] ci_hdrc ci_hdrc.1: at ci_runtime_suspend
[ 25.529596] usb_phy_generic usbphynop2: suspend
[ 25.534181] imx_usb 32e50000.usb: at imx_controller_suspend

I then went ahead and just commented out imx_controller_suspend() in drivers/usb/chipidea/ci_hdrc_imx.c which works around this issue.

However, now I am, of course, wondering what/why exactly this issue seems to be there in the first place. Unfortunately, neither NXP's reference platform nor any of our regular Toradex carrier boards can be used to reproduce this issue.

Is this a known issue like e.g. errata e11231 (USB: Clock must remain on during suspend/resume) on the i.MX 8M?

How may it be properly fixed?

[Harvey021]

Hello marcelziswiler

I have got update from our expert regarding this issue.

• IMX8MMINI doesn't have the Errata (USB: Clock must remain on during suspend/resume).
• And then, What's update on USB configuration in source code? Can you please share the schematic of USB part on core board and base board? 

        If the schematics of USB part for both core and base board are not available for sharing over here, then is that okay for you to raise another          ticket for the schematic sharing? The portal for ticket raise for your reference: Support | NXP Semiconductors

Best Regards

Harvey

[marcelziswiler]

> And then, What's update on USB configuration in source code?

The complete Linux kernel sources may be found on our git server.

https://git.toradex.com/cgit/linux-toradex.git/log/?h=toradex_5.4-2.3.x-imx

The mentioned hack to make it work looks as follows.

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
index c1d98af3f91bb..a652a5b5ada71 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -545,25 +545,7 @@ static void ci_hdrc_imx_shutdown(struct platform_device *pdev)
 static int __maybe_unused imx_controller_suspend(struct device *dev,
                                                 pm_message_t msg)
 {
-       struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
-       int ret = 0;
-
-       dev_dbg(dev, "at %s\n", __func__);
-
-       ret = imx_usbmisc_suspend(data->usbmisc_data,
-                                 PMSG_IS_AUTO(msg) || device_may_wakeup(dev));
-       if (ret) {
-               dev_err(dev,
-                       "usbmisc suspend failed, ret=%d\n", ret);
-               return ret;
-       }
-
-       imx_disable_unprepare_clks(dev);
-       release_bus_freq(BUS_FREQ_HIGH);
-       if (data->plat_data->flags & CI_HDRC_PMQOS)
-               pm_qos_remove_request(&data->pm_qos_req);
-
-       data->in_lpm = true;
+       dev_dbg(dev, "at %s NOT SUSPENDING!\n", __func__);
 
        return 0;
 }

> Can you please share the schematic of USB part on core board and base board?

> If the schematics of USB part for both core and base board are not available for sharing over here, then is that okay for you to raise another ticket for the schematic sharing?

Yes, I shared it via support ticket.

Case Number : 00443168.

[dlang]

Hello marcelziswiler,

are you able to share the result or solution to your problem?

I'm facing a similar issue, where a connected thumb drive is only detected when connected on boot up. Otherwise autosuspend is never left.

For some unknown reason it seems like U-Boot triggers the problem. When usb start is issued in U-Boot before booting, autosuspend doesn't work. When usb isn't started autosuspend works.

Only solution I've found so far is disabling autosuspend in the kernel.

I'm using lf-5.10.y-1.0.0 from NXP for U-Boot and Linux on a custom imx8mn SOM.

[marcelziswiler]

> are you able to share the result or solution to your problem?

We now upstreamed the following solution:

https://lore.kernel.org/all/20220811140738.96348-1-dev@pschenker.ch/

> I'm facing a similar issue, where a connected thumb drive is only detected when connected on boot up. Otherwise autosuspend is never left.

> For some unknown reason it seems like U-Boot triggers the problem. When usb start is issued in U-Boot before booting, autosuspend doesn't work. When usb isn't started autosuspend works.

Hm, I guess that could be TF-A resp. power domain related. I remember actually having seen issues when pairing different versions thereof with other versions of the rest of the stack.

> Only solution I've found so far is disabling autosuspend in the kernel.

> I'm using lf-5.10.y-1.0.0 from NXP for U-Boot and Linux on a custom imx8mn SOM.

We actually never used any 5.10 based NXP downstream. Our BSP 5 was still based on 5.4.70_2.3.0 and our BSP 6 is now based on 5.15.32-2.0.0.