On 30/01/17 14:59, Felipe Balbi wrote: > > Hi, > > Roger Quadros <rogerq@xxxxxx> writes: >>> (hmm, I didn't receive your reply in my intel inbox, only >>> gmail. Odd. Replying to myself here, but it should be on your reply, >>> rater). >>> >>> Felipe Balbi <balbi@xxxxxxxxxx> writes: >>>>> The previous commit c499ff71ff2a281366c6ec7a904c547d806cbcd1 is fine. >>>> >>>> okay. Then let's try to figure out what's going on. A diff of regdump >>>> before and after suspend/resume might start to give some clue about >>>> what's going on. DWC3 tracepoints should help too. Care to get those? >>>> BTW, is this dwc3 as host or peripheral? >>> >>> You don't have any endpoints enabled: >>> >>> -DALEPENA = 0x0000000f >>> +DALEPENA = 0x00000000 >> >> Thanks for the hints. >> >> This problem is because reason dwc3_gadget_run_stop() is timing out >> during the suspend sequence and so dwc3_disconnect_gadget() and >> __dwc3_gadget_stop() are not being called. > > I see > >> dwc3_suspend() does not consider dwc3_gadget_suspend()'s return value >> and happily continues suspending the machine. >> >> If I force dwc3_gadget_run_stop() to return 0 then everything works fine. >> >> Any ideas why DWC3_DSTS_DEVCTRLHLT is not getting set? > > no idea. It should always get set when run_stop is cleared. Can you > check if suspending with cable detached has any difference? > After cable detach, it still timed out the next suspend. But on subsequent suspends there were no timeouts. (I didn't plug the cable back at all) This behaviour is on dra7. I will test the behaviour on am43x as well. cheers, -roger -- 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
