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);
--
BR,
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
