Hello Peter, On 16-01-13 10:33:06, Peter Chen wrote: > 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) Sorry it's not clear to me what you are implying below. As in I should implement this in suspend resume path or are you just implying that this is what happens in the above case? > > > > 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. Can you clarify how and at what point? At first I assumed you are referring to the fact this could be done from user space as well. So I used a test code to send a usb control msg with request as USB_REQ_(SET/CLEAR)_FEATURE and feature as USB_PORT_FEAT_POWER using libusb and I can control the USB power on/off for any of the ports. This does not work however after resume from suspend. - Sanchayan. > > > 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
