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!
Solved! Go to 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.
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
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.
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
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.
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!
-----------------------------------------------------------------------------------------------------------------------
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.