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. 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 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. 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? It is also surprising that disconnect line and ip fix are needed while the TRM states that writing to bits 17 and 18, which is BM_USBPHY_IP_FIX, will not gaurantee chip functionality if set. However, I also checked this is required else one gets enumeration errors as stated by Stefan in his patch which introduced it. Any inputs are welcomed. 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 -- 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
