USB suspend resume issue on Vybrid

Technical Support
,
1

This issue was discussed already on another community forum [1]. But that thread does not provide a solution.

Here is a dump of a suspend/resume cycle (with some register prints):

[   40.868038] PM: Syncing filesystems ... done.                                                                                                            
[   40.885067] Freezing user space processes ... (elapsed 0.001 seconds) done.                                                                              
[   40.893418] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.                                                                         
[   40.902085] Suspending console(s) (use no_console_suspend to debug)                                                                                      
[   40.910656] ci_hdrc ci_hdrc.1: at ci_controller_suspend                                                                                                  
[   40.910698] suspend 1: USBPHY1 CTRL: 0x263cc042                                                                                                          
[   40.910706] suspend 2: USBPHY1 CTRL: 0x263cc042                                                                                                          
[   40.910752] imx_usb 400b4000.usb: at imx_controller_suspend                                                                                              
[   40.910762] mxs_phy_set_wakeup 1: USBPHY1 CTRL: 0x263cc042                                                                                               
[   40.928432] ci_hdrc ci_hdrc.0: at ci_controller_suspend                                                                                                  
[   40.928462] suspend 2: USBPHY0 CTRL: 0x263cc040
[   40.928766] mx4_io_spi spi1.0: Entering suspend state.
[   40.935823] mx4_io_spi spi1.0: Suspend succeeded after 0 retries
[   40.937277] imx_usb 40034000.usb: at imx_controller_suspend
[   40.937288] mxs_phy_set_wakeup 1: USBPHY0 CTRL: 0x263cc040
[   40.937626] PM: suspend of devices complete after 28.409 msecs
[   40.939065] PM: late suspend of devices complete after 1.417 msecs
[   40.940367] PM: noirq suspend of devices complete after 1.285 msecs
[   40.941772] PM: noirq resume of devices complete after 1.321 msecs
[   40.943048] PM: early resume of devices complete after 0.801 msecs
[   40.943615] imx_usb 40034000.usb: at imx_controller_resume
[   40.946003] mx4_io_spi spi1.0: Leaving suspend state.
[   40.973511] mx4_io_spi spi1.0: co-cpu responded within 0.027358657 seconds
[   40.973524] mx4_io_spi spi1.0: Wake-up succeeded after 0 retries
[   40.973676] ci_hdrc ci_hdrc.0: at ci_controller_resume
[   40.973688] mxs_phy_set_wakeup 1: USBPHY0 CTRL: 0xc0200040
[   40.973707] resume: USBPHY0 CTRL: 0xc0200040
[   40.974674] mxs_phy_set_wakeup 1: USBPHY0 CTRL: 0x80200040
[   40.977295] imx_usb 400b4000.usb: at imx_controller_resume
[   40.977316] ci_hdrc ci_hdrc.1: at ci_controller_resume
[   40.977324] mxs_phy_set_wakeup 1: USBPHY1 CTRL: 0xc0200040
[   40.977336] resume: USBPHY1 CTRL: 0xc0200040
[   40.978307] mxs_phy_set_wakeup 1: USBPHY1 CTRL: 0x80200040
[   41.009906] PM: resume of devices complete after 66.835 msecs
[   41.136278] Restarting tasks ... 
[   41.139685] mxs_phy 40050c00.usbphy: HS device has disconnected
[   41.139903] usb 2-1: USB disconnect, device number 2
[   41.161728] done.
[   41.170281] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
[   41.191448] option 2-1:1.0: device disconnected

Does Toradex know of this issue and is someone already working to fix it or is it already fixed?

A colleague of mine already posted on the NXP/Freescale thread also providing a workaround by doing a unbind/bind operation on the USB driver.

[1]. https://community.freescale.com/thread/375026

2

Hi Mirza,

Yes we are aware of this issue, see also [1]. @sanchayan.maity works on this and posted the Freescale/NXP community article. So far we do not have a solution, it seems that unbind/bind the driver could be a possible workaround…

[1] Toradex System/Computer on Modules - Linux BSP Release

3

Hi Stefan.

I looked at your BSP road-map yesterday but could not find that issue. You must have added it today :).

So far we do not have a solution, it seems that unbind/bind the driver could be a possible workaround…

I can confirm that unbind/bind works as a workaround for now, or at least that is what we are doing at the moment and it seems to be working.

If you find something we are happy to help testing it.

edit: Fixed a typo

4

Yes, we had it internally tracked and not published yet, I did that yesterday.

5

As reported by Niclas Lindgren on NXP Community and confirmed by @mirza.krak, unbind & (re)bind the driver works around this issue. Use the following command sequence to use this work around:

echo ci_hdrc.1 > /sys/bus/platform/drivers/ci_hdrc/unbind
echo mem > /sys/power/state
[...after wakeup]
echo ci_hdrc.1 > /sys/bus/platform/drivers/ci_hdrc/bind