On Mon, Aug 24, 2015 at 09:40:04PM +0530, Sanchayan Maity wrote: > Hello, > > I am working on Freescale Vybrid which is a Cortex A5 based SoC, > with a Chipidea based USB controller and a Sigmatel Phy or some- > thing 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. > > 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 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. > The PHY's clock may not be resumed correct, without normal PHY's clock, the writing to PHY's register has no effect. Check related PLL is on/enable, and output to USB PHY correct. > 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. > It seems the reset can work, and resume can not reset for PHY. > 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 and > USB miscellaneous register but with no results. > > Peter, Felipe do you have any ideas perhaps? From what I can see this > seems to be USB PHY issue. > Yes, it is PHY's suspend/resume issue. The current code follows the errata you refer. > Also Peter I wanted to ask you, the following bits > > MXS_PHY_ABNORMAL_IN_SUSPEND and MXS_PHY_SENDING_SOF_TOO_FAST where > are they being used? I can see the MXS_PHY_NEED_IP_FIX being used > but not the others. Perhaps I am missing something? There are un-upstream patch which add .notify_suspend/.nofify_resume after bus suspend/resume, in these two PHY's APIs, it will use these two flags. You can find these two APIs at freescale's released bsp. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
