On Tue, Jan 12, 2016 at 06:34:47PM +0530, maitysanchayan@xxxxxxxxx wrote: > 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) Clear PORT_PP (bit 12 at portsc) > -------------> set_port_feature(hub->hdev, USB_PORT_FEAT_POWER) Set PORT_PP (bit 12 at portsc) > > 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. > Just try to toggle port power to see if it can work for you. > 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 -- 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
