Hi, Roger Quadros <rogerq@xxxxxx> writes: >> 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. wonder if there's something odd with 2.02a. AM437x is 2.40a IIRC, testing that is, indeed, a good idea. -- balbi
Attachment:
signature.asc
Description: PGP signature
