On 15-08-25 10:37:27, Peter Chen wrote: > 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. Already checked that. The PLL registers related to USB seem to have the correct values after resume. Sorry forgot to mention this. UTMI clock is valid and PLL3 PLL7 used for USBs are shown locked by the ANADIG registers. > > > 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. Seems so. > > > 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. Ok. Found it in their 3.14 series and also your old v5 patchset. However .notify_suspend/.notify_resume seems to have been removed. From what I understand these would have run after the complete suspend/resume perhaps? I added the same in mxs_phy_suspend accordingly for lack of those notify calls, however that does not help. - Sanchayan. -- 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
