i.MX6Q: USB remote wakeup

[denisgrigoryev]

Hello!

I trying to get USB remote wakeup working on a custom i.MX6Q-based board. OS is android imx_L5.0.0_1.0.0-ga with linux-3.10.53.

I have high-speed USB device (GSM modem Cinterion PHS8-P) connected through USB Host 1.

System doesn't wakes up from memory sleep by remote wakeup signal initiated by the USB device.

That is what I do:

echo enabled > /sys/bus/platform/devices/20ca000.usbphy/power/wakeup

echo enabled > /sys/bus/platform/devices/2184200.usb/power/wakeup

echo enabled > /sys/bus/platform/devices/2184200.usb/ci_hdrc.1/power/wakeup

echo enabled > /sys/bus/platform/devices/2184200.usb/ci_hdrc.1/usb2/power/wakeup

echo enabled > /sys/bus/platform/devices/2184200.usb/ci_hdrc.1/usb2/2-1/power/wakeup

echo auto > /sys/bus/platform/devices/2184200.usb/ci_hdrc.1/usb2/2-1/power/control

Runtime PM works ok. I see suspend/resume messages in dmesg:

mxs_phy 20ca000.usbphy: HS device has suspended

ci_hdrc ci_hdrc.1: Remote wakeup is enabled, and device is on the port

ci_hdrc ci_hdrc.1: at ci_runtime_suspend

imx_usb 2184200.usb: at imx_controller_suspend

imx_usb 2184200.usb: at imx_controller_resume

ci_hdrc ci_hdrc.1: at ci_controller_resume

mxs_phy 20ca000.usbphy: HS device has resumed

mxs_phy 20ca000.usbphy: HS device has suspended

ci_hdrc ci_hdrc.1: Remote wakeup is enabled, and device is on the port

ci_hdrc ci_hdrc.1: at ci_runtime_suspend

imx_usb 2184200.usb: at imx_controller_suspend

but once system goes to suspend it have no reaction to resume signal.

I have no possibility to connect a different device to USBH1. A full-speed device (e.g. mouse, keyboard) connected to USB_OTG seems to work normally: resume signal causes system wakeup.

Please point me in the right direction.

Thank you!

[CarlosCasillas]

Hi Denis,

Have you tried asking for a custom driver with the manufacturer of the GSM modem? In the meantime, I have internally asked if Freescale BSPs support remote wakeup on CDC Devices (like the GSM modem).

Hope this will be useful for you. I will send you an update soon.

Best regards!

/Carlos

[denisgrigoryev]

Hi, Carlos!

Thank you for reply.

Modem uses "option" USB-serial driver. There is no custom driver for this modem.

I saw resume signal on the oscilloscope, so I think the modem behaves correctly. In case of runtime PM I see "Resume" signal (K state for 2.5 ms) driven by modem, then some time more driven by iMX6 (it looks like a small level change) as it should be. Once whole system goes to sleep I see only first 2.5 ms, then followed by "Disconnect" state without any reaction from iMX6. The "Resume"-"Disconnect" signal constantly repeats until I press the "Power" key to resume the system. In about 70% of cases USB host and the modem continue to work normally. I see re-enumeration in about 30% cases, because of "Disconnect" state, I think.

I'm waiting for an update. Thank you!

Regards,

Denis.

[CarlosCasillas]

Hi Denis,

AE team has commented the following:

Can you measure the USB bus state with a scope and capture the remote wakeup request?

During suspend you should see a FS_J state  (= Dp@ ~3.2V, DM@ ~0V) Remote wakeup changes this to FS_K (Dp = 0V, Dm = ~ 3.0V). After that, the host shoud start driving the bus and send SOF.

Also measure VBUS at this time.

Best regards!

/Carlos

[denisgrigoryev]

Hi Carlos,

The first picture demonstrates a normal wakeup process. CPU is awake, USB runtime power management is enabled. The USB modem is a high speed device connected to USBH1.

The blue line is Vbus, yellow is Dp and green is Dm.

The images below is a failure state at various zoom levels. CPU is in memory sleep, USB wakeup enabled, power control is "auto":

echo enabled > /sys/bus/platform/devices/20ca000.usbphy/power/wakeup

echo enabled > /sys/bus/platform/devices/2184200.usb/power/wakeup

echo enabled > /sys/bus/platform/devices/2184200.usb/ci_hdrc.1/power/wakeup

echo enabled > /sys/bus/platform/devices/2184200.usb/ci_hdrc.1/usb2/power/wakeup

echo enabled > /sys/bus/platform/devices/2184200.usb/ci_hdrc.1/usb2/2-1/power/wakeup

echo auto > /sys/bus/platform/devices/2184200.usb/ci_hdrc.1/usb2/2-1/power/control

echo mem > /sys/power/state

Device repeatedly tries to wake the CPU up driving the FS_K state for 2.5 ms. After that a 1 us spike can be seen, looking like a tristate with pull-up connected. The hub wouldn't propagate resume signalling but seems to signal SE0 instead for another 2.5 ms. The CPU wouldn't wake up.

Regards,

Denis.

[CarlosCasillas]

Hi Denis.

Below you can find additional response from AE team:

I checked with design for any known issues.

Design believe the 2.5 ms resume_K from the device may be too short if the 24 MHz oscillator was shut down in system suspend.

What I think you may be seeing in the scope traces is the device driving FS_K state for 2.5 ms, then the host does not take over driving FS_K so the device sees an end of resume signaling and it enables HS termination. This will pull DM and DP low. The Host may see this as a disconnect since it is still in FS mode. After 3 ms, the device has only seen HS-idle and enters suspend state. This means the FS termination is enabled again, including Dp-pull-up,  and DP returns to 3.2V.

Please check if the system starts up quickly enough for the host controller & driver to respond to the resume signaling.

Hope this will be useful for you.
Best regards!
/Carlos

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[denisgrigoryev · Accepted solution]

Hi Carlos,

Thank you for reply.

I found the root of our problem.

We had USB_H1_OC function configured  by u-boot. Default USBNC.OVER_CUR_POL and USBNC.OVER_CUR_POL state is 0. That is wrong for our schematics, we use active-low OC signal so it was always asserted. I configured controller properly and remote wake up now works.

Also I noticed, that SABRESD board do not use USB_H1_OC and USB_H1_PWR functions at all. It use GPIO controlled by regulator-fixed for power control. Because of this VBUS is not controlled by USB_PORTSC.PP bit and overcurrent signalling and recovery is not working despite the fact that the board has MIC2026 IC.

Thank you for support!

Best regards!

Denis.