DM3730: Suspend issues with OTG USB

I am not sure if this is related, but the TPS65921 PMIC will not power off its outputs while VBUS is present.  I am not sure if the TPS65930 has this same feature.

I was told this feature was added because many of the PMIC devices were designed for mobile battery powered products where the USB PHY is operating as USB peripheral and customers want the PMIC to apply power to the processor when a valid VBUS is sourced from the host.

Are you providing an external VBUS power source since you are operating as USB host?  If so, did you turn off this power source to VBUS?

Regards,

Paul

That is a VERY good point.  I'll take a look at that.

Well, it was a good thought, but I checked the schematic and we're not supplying an external source for VBUS - we're relying on the TPS65930 to supply that 5V, so there's nothing external that needs to be shut down.

Of course, VBUS isn't going low during the suspend process... but that's likely just because the OTG module isn't going into suspend properly for whatever reason.  Anything other dependencies like that one that I can check?

Can you try below patch ?

http://marc.info/?l=linux-usb&m=129975136202670&w=2

Thank you for the response, but it seems to have the same effect with that patch applied.

Here's an interesting find.  If I set the Driver Mode to "Both host and peripheral", it suspends CORE just fine.  Switch it back to "USB Host", and it does not suspend CORE.  Any idea how to get it to work successfully in host-only mode?

Also tried the patch at http://arago-project.org/git/people/?p=sriram/ti-psp-omap.git;a=commitdiff;h=7719b06aaac0b5bdd02177308e5fdf82951b7e67, but it's still doing the same behavior.

Based on the observation that it works only in OTG (host and peripheral) and also on the comment that Vbus is on and might be preventing the system to enter into off mode; Please try below change and see if you see any difference.

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 98874c5..283f9ce 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -799,7 +799,7 @@ static irqreturn_t musb_stage2_irq(struct musb *musb, u8 int_usb,
                case OTG_STATE_A_SUSPEND:
                        usb_hcd_resume_root_hub(musb_to_hcd(musb));
                        musb_root_disconnect(musb);
-                       if (musb->a_wait_bcon != 0 && is_otg_enabled(musb))
+                       if (musb->a_wait_bcon != 0)
                                musb_platform_try_idle(musb, jiffies
                                        + msecs_to_jiffies(musb->a_wait_bcon));
                        break;

The patch would switch off the vbus when all the devices are disconnected even in host only mode.

Regards,
Ajay

Thank you for your suggestion.  With that change in place, the behavior that I've noticed so far is that, after a device disconnect, it will fail to notice any future device connects.  Also, it does not appear to have any effect on the suspend process, either before or after a device disconnect.  Since it's having a negative effect, I'm going to remove it for now.  Please let me know what other thoughts you might have on this issue.

Thats expected with this change. You need to start the session to get devices detected using "echo F > /proc/driver/musb_hdrc" or "echo 1> /sys/devices/platform/musb_hdrc/srp"

anyways you can always choose to build in OTG mode which will work properly in host scenarios as well.

Regards,

Ajay

Ok, nice.  With that command, I'm able to reconnect devices with that patch.  However, it's still not actually suspending the power domain.

I went back and tested OTG mode.  Looks like in my test before, I had an invalid config, and OTG USB wasn't actually starting properly.  Fixing that, and actually getting working USB in that mode, I see now that it's doing the same behavior (core power domain not suspending, CM_CORE->CM_IDLEST1_CORE shows that OTG USB is still Active).

I will pull out some of these patches and re-attempt under OTG mode.

1362.glennw_config.txt

Still same issue without all the changes.  Attached is my current .config to give you a bit more information - perhaps I'm simply missing something there.

I note that twl4030-usb.c::twl4030_set_suspend is not actually being called on suspend.  Perhaps that has something to do with it?

I have just a couple of thoughts on this, the first is just a verification, I am curious if you were able to verify that the provided patch actually shut down the VBUS rail (i.e. checked with a multimeter) when attempting to suspend, if so that would put us outside Paul's initial suggestion that the VBUS voltage was keeping the TPS active, so we can look at other options.

The other thought would be to try this on a EVM board, or other known good TI board like Beagle if you happen to have one, to see if this is unique to the TPS65930 implementation on the custom board. The TI boards use a TPS65950 in place of the TPS65930, however it should be entirely software compatible, so there is some possibility of reproducing this on TI hardware in which case it will be easier for TI to reproduce and possibly file as a bug. If it turns out that the problem does not happen on the TI board, than we may want to start going down the deltas between the custom board and the TI board.

Can you try below change in musb_core.c. It seems to break musb pm with TPS PHYs.

--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2406,7 +2406,6 @@ static int musb_suspend(struct device *dev)
        struct platform_device *pdev = to_platform_device(dev);
        unsigned long   flags;
        struct musb     *musb = dev_to_musb(&pdev->dev);
-       u8 reg;

        if (!musb->clock)
                return 0;
@@ -2423,10 +2422,6 @@ static int musb_suspend(struct device *dev)
                 * resume to make the gadget functional thus doing a force
                 * disconnect.
                 */
-               reg = musb_readb(musb->mregs, MUSB_POWER);
-               reg &= ~MUSB_POWER_SOFTCONN;
-               musb_writeb(musb->mregs, MUSB_POWER, reg);
-
        } else if (is_host_active(musb)) {
                /* we know all the children are suspended; sometimes
                 * they will even be wakeup-enabled.

REgards,
Ajay

Bernie and Ajay,

Thank you for the excellent responses.  I had removed the VBUS patch because I am now back in OTG mode instead of Host-Only, should I put it back in?  Anyway, that latest patch had an interesting effect.  Let me go through the various states that I'm seeing and I'll tell you what's happening (along with the VBUS state at each step).

After boot, no USB device inserted:  Suspend failed, VBUS high during suspend
After boot, USB device inserted: Suspend Success! VBUS high during suspend
USB device removed: Suspend Success!  VBUS low
USB device re-inserted (after USB session started): Suspend Success! VBUS high
USB device removed again: Suspend Success!  VBUS low

It appears that with this latest patch, suspend is successfully shutting down the core powerdomain only after a USB device has been inserted into the system once.  From then on out, it successfully suspends in any state.  Before that, it has the same behavior as before.  So we're 90% of the way there - what needs to change in the init process to get it to work after boot?

Thanks,

Glenn Wainwright

Glenn,

Can you now use the below patch which SHin had pointed out earlier,

http://marc.info/?l=linux-usb&m=129975136202670&w=2

Regards,
Ajay

Glenn,

There are some bugfx patches on twl4030 driver in latest kernel tree. Please check them at,

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/usb/otg/twl4030-usb.c;h=e01b073cc489e0d2e209680441e2e81f40c306ac;hb=fafc9929c668f8bae6dd1f109f33a86d2cb3c460

Some of them seems to be related to the observation you have.

Regards,
Ajay

I re-applied the suspendm patch, and it has not seemed to change much.  I will take a look at the twl4030 patches and see what I'm missing from there.

Before that, though, I wanted to mention an observation that I made this morning that might help.  I noticed that if I did the "echo F > /proc/driver/musb_hdrc" without then inserting a USB device, I could reproduce the suspend issues that I saw after initial boot.  On inserting a USB device, the system would then be able to sleep as normal.  

Not sure if that helps, but it seemed an interesting observation.

Thanks,
Glenn Wainwright 

Looking at the changes to the twl4030 driver, I thought you really had the answer - there were a few changes there that seemed to apply directly to this issue.  However, I installed all of the patches, and the behavior seems to be no different.  Is there any debugging information that I could provide to help?

Dear Glenn,

I have same behavior as you mentioned (no USB - CORE domain is not going to sleep). I am using Windows CE 6.0 and AM3715.
Did you find solution? What was the problem?
I compared all registers related to PRM and CM and also check everything what is mentioned here: http://processors.wiki.ti.com/index.php/OMAP35x_and_AM/DM37x_Debug_Steps_for_Idle_Entry and everything looks correct. 

Patrik

I found solution, but it is very dirty and I don't understand what is cause of this behavior: When I enable trace messages in StartUSBClock() and StopUSBClock() in beginning and end of this function, than device is going correctly to sleep mode even without USB cable connection. I have tried to replace this trace function with some wait cycle (2 ms), but this didn't help. It is look like that if Start and Stop USB clock are called very fast many times, that something corrupt internal state of chip, because all registers (CM and PRCM) are the same in booth cases (sleep and don't sleep). 

Did somebody other find this strange behavior?

Patrik