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);
>
I had tried this already but in the ci_controller_resume path and since I was
not sure I had also first tried clearing and setting separately in the suspend
resume path. But none of the above three trials worked.
- Sanchayan.
--
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
