Hello,
I am trying to make a WP7607 go into sleep mode with an OTG ethernet controller connected to it.
I have tried a whole bunch of things, and at last the sequence that I found that takes me ever so close to success is the following:
0. I have recompiled the kernel, enabling debug user control of the OTG mode (host and peripheral) by overriding the following in the WP7607 device tree.
&soc {
usb_otg: usb@78d9000 {
qcom,hsusb-otg-otg-control = <3>; /* User control */
//qcom,hsusb-otg-delay-lpm;
};
};
This lets me control via /sys/kernel/debug/msm_otg/mode the OTG configuration as follows.
I plug my OTG ethernet controller/flash drive/keyboard or nothing at all and turn on my device (This also works on the reference MangOH Red board)
I check via lsusb that no Bus 001 Device 001: ID 1d6b:0002 is shown.
I set it on peripheral mode, by cutting VBUS power and by sending echo -n peripheral > /sys/kernel/debug/msm_otg/mode; sleep 1; cat /sys/kernel/debug/msm_otg/mode, then I give VBUS power again.
The kernel prints me back this:
[ 77.035243] msm_otg 78d9000.usb: Could not get usb power_supply
[ 77.035284] msm_otg 78d9000.usb: Could not get usb power_supply
[ 77.039999] msm_otg 78d9000.usb: Could not get usb power_supply
[ 77.040010] msm_otg 78d9000.usb: Could not get usb power_supply
I send AT+KSLEEP=0, the device sleeps as expected.
I wake up the device. It does so as expected.
I put the device on host mode, by unpowering VBUS, then echo -n host > /sys/kernel/debug/msm_otg/mode; sleep 1; cat /sys/kernel/debug/msm_otg/mode and giving VBUS power again.
The kernel prints me this:
[ 264.151050] usb usb1: runtime PM trying to activate child device usb1 but parent (msm_hsusb_host) is not active
I check via lsusb that both the ID 1d6b:0002 and the OTG device is present.
If I go to sleep at this stage, the OTG device prevents me from going, as expected.
I turn off the VBUS power again, get back into echo -n peripheral > /sys/kernel/debug/msm_otg/mode; sleep 1; cat /sys/kernel/debug/msm_otg/mode .
When the device goes to sleep now, it will enter a strange state, where the CPU is actually sleeping but I still get echo loop from the serial UART interface. If I then try to wake up with an interrupt, the device gets stuck until I unpower and power back the device.
To make it short, every time the device enters host mode and gets back into peripheral mode, no matter if an OTG device is plugged or not / the VBUS has the power cut or not / If I go to sleep during each stage or skip it. Nothing I do makes an obvious difference, it all leads to a total block of the CPU, unless I reboot the device, then the device is able to sleep. I suspect that something is not configured back correctly in kernel/drivers/usb/phy/phy-msm-usb.c when hopping between work modes.
Thank you for your help.
Without applying this patch, even if I’m in peripheral mode, if I got an OTG device connected, the device will never enter sleep mode, but it doesn’t affect the issue that I’m encountering, switching from host mode to peripheral mode breaks sleep mode, and the CPU never wakes, unless I reboot via command or I unplug the device.
In regards of R16.3, I cannot use it, since I’m relying on the “newer” 4.14 kernel for some of my device functionalities.
Thank you for your time.
If there are tests to do and patches you want me to apply, I will be more than happy to assist and help you. I’m not particularly skilled in C, but I suspect there’s something that gets configured by kernel/drivers/usb/phy/phy-msm-usb.c when hopping into host mode and that it doesn’t go back as it should when going back into peripheral mode, causing this mayhem.
Thank you for your reply. I was already unpowering VBUS via hardware, I am not aware of a method to cut power to VBUS via a console command.
Regarding R16.3, I guess I can download it, apply the manual OTG control patch in the first post and try if it works there. I want to reiterate that, even if OTG sleep works there, downgrading to R16.3 is not a solution to my issue, since I need most of the changes that were made in the 4.14 Kernel.
What if not setting “peripheral” but just cut powerof vbus?
Will that be the same as as removing device from the uab otg directly?
I am thinking you can start with usb thumb drive
Once remove the drive physically, can the module go to sleep mode?
And then if you cc onbect the usb thumb drive after that, can it be working?
Btw, since your module now in r17, it cannot go back to r16.3.
You need to take another module to test
I found that I have similar test before in FW R16:
At that time, in order to go to sleep mode, I need to first connect to a PC host so that /sys/kernel/debug/msm_otg/otg_state from a_host to b_peripheral
(BTW, I saw you just echo host / peripheral, but not sure if it should be a_host / b_peripheral)
Lastly, have you tried to use the USB port in mangoh red board which is using HSIC instead of using the USB OTG cable like this in mangoh green board?
I have just tried to use the USB port in mangoh red board which is using HSIC like the picture above with FW R16.3, module can go to sleep mode when connected with USB thumb drive.
So you might double check whether you can use this HSIC USB port.
Hi, sorry for the late response, the company was on break.
I took a step back and reassessed if the bug was caused by the manual hsusb-otg-otg-control, so I asked my colleagues for a OTG cable with a switch on the ID pin, so that I could control the OTG status without unplugging cables. I’ve tested this both on R16.3 and R17, and as expected, nothing changes on R17, locking up on sleep after plugging ID to host mode and unplugging it back, while on R16.3 it works, after going to sleep mode the device is perfectly able to wake up again without a hitch. As for the modem datasheet specs, VBUS needs to be cut or applied every time the ID pin is acted upon. This happens by using a NOT gate on the USB_ID pin, as shown. So, if an OTG adapter is present, it will be detected and the VBUS voltage will be applied, otherwise, it will be removed.
I plug my cable, with OTG ID on low state. The device is happy on sleep and resume.
I unpower VBUS and put ID on high, then I power VBUS back on. This makes the OTG device appear alongside the USB 2.0 root hub.
I unpower VBUS, switch ID back on low (and optionally put VBUS back on). When I tell the device to go in KSLEEP=0, the CPU will halt, the serial will still send local echo, and when I wake it up via GPIO the CPU won’t wake up anymore, needing a hard poweroff.
I have also tried plugging the WP7607 back to a PC before KSLEEPing, but nothing changes.
In regards to the HSIC port, I unfortunately can’t use without a whole board redesign, our device microUSB port is the same as the MangOH Red’s CF3 microUSB port.
I wish I could use R16.3, but I need to use the newer device drivers and kernel support that R17 comes with.