Hello Peter, I had reported the suspend resume issues on Vybrid and recently there have been some developments after one of our customers reported the below sequence of operations which worked for them. By doing the following sequence of operations after resume echo ci_hdrc.1 > /sys/bus/platform/drivers/ci_hdrc/unbind echo ci_hdrc.1 > /sys/bus/platform/drivers/ci_hdrc/bind the USB ports start working. This is observed in presence of external hub connected to the root hub or in the presence of root hub alone. After trying to trace through the sequence of operations which happen on bind, roughly are as below, probe() call in chipidea/core.c -> probe() call in hub.c ----> hub_configure() -------> hub_activate(hub, HUB_INIT) ---------> hub_power_on(hub, false) -------------> set_port_feature(hub->hdev, USB_PORT_FEAT_POWER) set_port_feature() now sends a control urb. Exactly after this the ports start working. This hub_configure() is not called during the regular resume() sequence. I am not well versed with USB specifications or stack to draw an inference from this concretely. Can you throw some light on this if possible? Is it possible, to accomodate this somehow in the regular sequence of operations which happen on resume? The set_port_feature is in the core usb code and am not sure how to generically access it. We are currently using the 4.1.15 kernel with our patches on top of it. Regards, Sanchayan. On 15-08-24 21:40:04, 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. > > 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
