USB suspend resume issue on Vybrid

[sanchayanmaity]

Hello,

I am working on Freescale Vybrid with a Chipidea based USB controller and a Sigmatel Phy or something if my memory serves me right. We are currently in the process of implementing suspend resume and fixing related issues. After resume the USB PHY does not come up and the USB subsytem prints

[129.570097] usb 1-1: USB disconnect, device number 2

which comes from the core code in hub.c.

I am using the 4.1.5 kernel with some of our own patches especially with regards to suspend resume being present only in our own tree which we plan to eventually push out to mainline.

From what I can see, the USB USBPHYx_PWDn register which has bits related to power down, all stay in their default "1" state which denotes power down, after resume. Now this is in spite of the fact that the code seems [2] to write 0 to the register on resume. However, doing a quick check with devmem2 shows the register to have the default values of "1" denoting power down. So write seems to have no effect at all.

Instead of the code at lines 392[1] and 394[2] if I do

return mxs_phy_hw_init(mxs_phy);

on resume, the USBPHYx_PWDn seems to have the correct value of all bits as zero. However of course, the USB PHY does not come up. The stmp block reset in mxs_phy_hw_init seems to make the write work.

There is an errata for Vybrid at [3] in VYBRID_2N02G going as e4535: USB: USB suspend and resume flow clarifications. Not sure if I understand the explanation, however the following workaround which the errata mentions:

To place the USB PHY in low power suspend mode, the following sequence should be performed in an atomic operation. (interrupts should be disabled during these three steps)

1. Set the PORTSC1.PHCD bit

2. Set all bits in USBPHY_PWD register

3. Set the USBPHY_CTRL.CLKGATE bit

These sequence of steps seem to be correctly followed in the suspend code [4] of Chipidea IP AFAICT.

I am not that well versed with USB subsystem code having only worked on it once before for fixing non working USB client on Vybrid [5]. Have tried messing with different register bits in the USB PHY, USBPHY_CTRL and USB miscellaneous register like UTMI_SUSPENDM, HOST_FORCE_LS_SE0 and HOST_RESUME_DEBUG but with no results. Have already made sure that all the ANADIG and CCM registers are at their correct values after resume.

From what I can see this seems to be USB PHY issue.

MXS_PHY_ABNORMAL_IN_SUSPEND and MXS_PHY_SENDING_SOF_TOO_FAST, these two flags are not implemented in mainline. However implementing them with old patches from mainline and the way it is done in Freescale's 3.14 kernel release does not help either.

Is there an errata with the USB suspend resume issue of Chipidea IP core and Sigmatel PHY on Vybrid? Can anyone from Freescale or one of the hardware IC engineers know of steps to bring up the USB PHY on resume?

Thanks & Regards,

Sanchayan.

[1]. http://lxr.free-electrons.com/source/drivers/usb/phy/phy-mxs-usb.c#L392

[2]. http://lxr.free-electrons.com/source/drivers/usb/phy/phy-mxs-usb.c#L394

[3]. http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=VF6xx&fpsp=1&tab=Documentation_Tab

[4]. http://lxr.free-electrons.com/source/drivers/usb/chipidea/core.c#L891

[5]. https://lkml.org/lkml/2014/12/19/110

[CommunityBot · Accepted solution]

This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!

[markwilliams]

Hi, have you seen ERR004535 USB: USB suspend and resume flow clarifications. This seems to describe the issue you have been having.

I have also had issues with the PHY resume from suspend on the i.mx28. My current work around being not to suspend the PHY.

mark

[richard_stulens]

The problem that you are facing is likely that the controller sends HS SOF before the device has returned to HS mode after a resume. This will lead to a disconnect detection in the PHY.

Please try setting bit 18 in the USBPHYx_IPn register. This will add delay so the SOF will not be sent before the device has HS termination enabled.

This will be in the next revision of the RM.

Also set bit 17. This corrects an issue in the PHY. When this bit is not set, some devices may not wake up.

Best regards,

Richard

[sanchayanmaity]

Hello Richard,

I have already tried setting those two bits.

We already take care of these bits during initialisation, see [1] and [2]. While they are not set up in the resume code path [3], I have already tried setting them when the PHY resume code is called but that does not help.

We have known about these bits for quite a while and if my memory serves me right, my colleague added the patch for introducing it for Vybrid.

- Sanchayan.

[1]. Linux/drivers/usb/phy/phy-mxs-usb.c - Linux Cross Reference - Free Electrons

[2]. Linux/drivers/usb/phy/phy-mxs-usb.c - Linux Cross Reference - Free Electrons

[3]. Linux/drivers/usb/phy/phy-mxs-usb.c - Linux Cross Reference - Free Electrons

[richard_stulens]

Hi Sanchayan,

Can you then try to disable the HS disconnect detector in the PHY (HW_USBPHY_CTRL.ENHOSTDISCONDETECT) when the host port is suspended, and re-enabled after resume. This was the workaround before the hardware assist was added.

Let me know if this solves the problem.

Best regards,
Richard

[sanchayanmaity]

Hello Richard,

Have already tried that as well. But just to be sure I tried it again.

That does not work either. I removed the phy_connect and disconnect functions which set/unset that bit here [1] and have the IP bits set in the resume path.

[1].  Linux/drivers/usb/phy/phy-mxs-usb.c - Linux Cross Reference - Free Electrons

- Sanchayan.

[richard_stulens]

Hi Sanchayan,

I re-read your original post and noticed I missed the part saying the PWD bits remain set after resume.

Since PWD and clock gate were set when entering suspend, they must be cleared prior to resume and in reverse order (CLKGATE before PWD)).

Also check if the USB PLL is running. This provides the PHY clock.

All of this is also required for i.MX6 so I expect it to be in the code somewhere. I'm not a Linux engineer so I do not know where to look.

As a test, you can suspend without putting the PHY in low-power mode and see if resume works properly.

Regards,

Richard

[richard_stulens]

Hi Sanchayan,

I'll verify this clearing of PWD and CLKGATE with our i.MX6 SW team. The USB PHY is identical to i.MX6.

Regards,

Richard

[sanchayanmaity]

Hello Richard,

I'll verify this clearing of PWD and CLKGATE with our i.MX6 SW team.

Thanks.

The USB PHY is identical to i.MX6.

Yes, it is. And since we also work on iMX6 I have looked into 3.14 Freescale vendor kernel for iMX6. The USB PHY code there implements two flags below.

MXS_PHY_ABNORMAL_IN_SUSPEND

MXS_PHY_SENDING_SOF_TOO_FAST

I also tried implementing them by using the 3.14 kernel and Peter Chen's old patches from here [1] as a reference because these are not implemented in 4.x kernels and they carry out specific operations in case they are set. I was hoping that might work but I did not see any changes.

I have made sure all ANADIG and CCM registers are at their correct values by manually noting each reigster's value before suspend and after resume. The PLL3 and PLL7 registers related to USB show that the USB clocks are enabled and the PLL is locked. The code also does it correctly so I do not expect them to be wrong and since I cross reference them with my manual checks as well.

Also have a quick look here [2]. One can see that the clock gate is being cleared prior to setting the USBPHY_PWD to zero. The surprising thing and which you noted recently from my first post is that the USBPHY_PWD registers stay at all "1"'s implying PWD even when the clockgate is removed and 0 has been written to that register. So basically writing a 0 to the PWD register somehow seems to have not effect at all!!! A software reset seems to be the only way to get it to have "0"'s in that register however not that it solves the issue.

I can also add that the USB controller peripheral seems to be fine or atleast it seems so. For example, if a manual restart is issued to the Chipidea controller (something which we do when we do on automatic gadget or host detection) the CI peripheral controller detects the device after having come out of resume, but one gets USB descriptor read errors due to the PHY being down and thus resulting in the controller being unable to communicate with the USB device in question.

[1].  Gmane Loom

[2].  Linux/drivers/usb/phy/phy-mxs-usb.c - Linux Cross Reference - Free Electrons

- Sanchayan.

[richard_stulens]

Hi Sanchayan,

I discussed with our SW engineer that does the Linux USB implementation for i.MX6.

He did not see an obvious reason for the problem. The most likely reason for PWD not to go to 0 is that the clock is still gated.

I assume you did check, but just be sure can you check if CLKGATE does effectively transition to 0 by reading it back?

Also check if the module clock (CCM_CCGR1[CG20] and/or CCM_CCGR7[CG116]) is running. It may have been turned off when suspend mode was entered.

Regards,

Richard

[sanchayanmaity]

Hello Richard,

Any more inputs?

Thanks & Regards,

Sanchayan Maity.

[richard_stulens]

Hi Sanchayan,

Sorry for the delay. The past few weeks a

I'm pretty much out of ideas. I see no reason why this would not work on Vybrid.

Can you dump the PHY registers? I'll check if everything is the way I expect it to be.

Can you capture the Dm and Dp bus state when the resume occurs? (use a 1 GHz or better scope when possible)

Aslo include VBUS_DETECT if possible.

Maybe this will tell us some more about the issue.

Best regards,

Richard

[sanchayanmaity]

Hello Richard,

Sorry for the delay in reply, had got tied up with another problem on a different platform.

Sure I will dump the PHY registers and share them here.

Sadly we only have a 200 MHz capable scope.

Thanks & Regards,

Sanchayan Maity.

[richard_stulens]

Hi Sanchayan,

Use the 200 MHz for now. It will not show much detail of the HS signal, but it may be good enough to see what happens upon resume.

Regards,

Richard

[sanchayanmaity]

Hello Richard,

Here are the PHY locations after resume,

USBPHY0_PWD                                0x001E1C00

USBPHY0_TX                                    0x10060607

USBPHY0_RX                                    0x00000000

USBPHY0_CTRL                               0x80200040

USBPHY0_STATUS                          0x00000000

USBPHY0_DEBUG                            0x7F180000

USBPHY0_DEBUG0_STATUS          0x00000000

USBPHY0_DEBUG1                          0x00001000

USBPHY0_VERSION                         0x04020000

USBPHY0_IP                                     0x00010000

The USBPHY1_* registers have the same value. Notice that after resume, the PWD registers indicate power down condition.

I will get back to you with the scope readouts some time later.

- Sanchayan.

[richard_stulens]

Hi Sanchayan,

It seems Soft Reset was set but not cleared, I think this will keep the PHY in RESET condition.

USBPHY0_CTRL                               0x80200040  ---> SFTRST (Soft Reset) is asserted !!

Regards,

Richard

[sanchayanmaity]

Hello Richard,

Yes that's right. However I do not know why it is so!

Even if I add code to manually clear the bit on resume it does not work. On doing so, the USBPHYx_CTRL now has 0x20000040, however PHY is still down even though the PHYx_PWD register now shows all 0! And I have tried changing the order of operations, clear clkgate first and then sftrst bit and vice versa, no results.

- Sanchayan.

[richard_stulens]

Hi Sanchayan,

I don't think the PHY should be reset for suspend. Try to find where the reset bis is set when entering suspend and remove the reset.

The Phy looks to respond correctly after you cleared the RESET. It may be out of sync with the controller because it was reset.

Regards,

Richard

[sanchayanmaity]

Hello Richard,

SFTRST is only set and cleared once during boot up. Nothing else sets this bit in the code in any of the other code paths  except during initialisation at power on.

- Sanchayan.

[richard_stulens]

Hi Sanchayan,

The reset bit must have been set by some code, maybe incidentally.

The PHY is responding correctly after you cleared the reset, but since the reset was set, the PHY's configuration may be out of sync with the controller and in the wrong state for a resume.

I think we are now at the point where help from timesyssupport is more appropriate since this is now Linux driver support.

Best regards,

Richard