>
> Hello Peter,
>
> On 16-01-14 11:12:32, Peter Chen wrote:
> > On Wed, Jan 13, 2016 at 6:12 PM, <maitysanchayan@xxxxxxxxx> wrote:
> > > 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.
> > >
> >
> > Hi Sanchayan
> >
> > I just tried below commands, it will remove the chipidea core device,
> > and re-initialize it.
> > It means it will reset controller as well as reset PHY. (the
> > connection will be lost).
> > But we do not reset them during the suspend/resume routine.
> >
> > >> > echo ci_hdrc.1 > /sys/bus/platform/drivers/ci_hdrc/unbind
> > >> > echo ci_hdrc.1 > /sys/bus/platform/drivers/ci_hdrc/bind
> >
> > If you would like to try if toggle port power can work or not during
> > the resume routine, try below code please:
> >
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index 7404064..00d73c9 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -1195,6 +1195,10 @@ static int ci_resume(struct device *dev)
> > if (ret)
> > return ret;
> >
> > + hw_write(ci, OP_PORTSC, BIT(12), ~BIT(12));
> > + udelay(10);
> > + hw_write(ci, OP_PORTSC, BIT(12), BIT(12));
> > +
> > if (ci->supports_runtime_pm) {
> > pm_runtime_disable(dev);
> > pm_runtime_set_active(dev);
> >
>
> Do you have any further suggestions that I might try?
>
> I also implemented the below changes which exist in Freescale iMX 3.14.52
> kernel, to see if they work. Earlier I had implemented only the mxs_phy
> specific code in the suspend/resume path which did not work. This time I
> implemented the complete relevant code.
>
Since I don't cover Vybrid, I don't know what's any special for it.
>From your original post, the phypwd is still 1 even you clear it.
It means the PHY (or it's clock) is abnormal, try to reset PHY (using mxs_phy_init)
after system resumes.
Peter
��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
