Hi, John Stultz <john.stultz@xxxxxxxxxx> writes: > On Fri, Jul 3, 2020 at 2:54 AM Felipe Balbi <balbi@xxxxxxxxxx> wrote: >> John Stultz <john.stultz@xxxxxxxxxx> writes: >> > I was curious if you or anyone else had any thoughts on how to debug >> > this further? >> >> Try enabling dwc3 tracepoints and collecting working and failing >> cases. If I were to guess, I would say there's a small race condition >> between setting pullup and the transceiver sending the VBUS_VALID signal >> to dwc3. > > Trace logs attached. Let me know if you have any further ideas! You can see from failure case that we never got a Reset event. This happens, for instance, when dwc3 doesn't know that VBUS is above VBUS_VALID threshold (4.4V). When the problem happens, I'm assuming USB is completely dead, meaning that keeping the cable connected for longer won't change anything, right? In that case, could you dump DWC3 registers (there's a debugfs interface for that)? I'm mostly interested in the PHY registers, both USB2 and USB3. Check if the PHYs are suspended in the error case. If they are, try enabling the quirk flags that disable suspend for the PHYs (check binding documentation). If that helps, then discuss with your Silicon Validation guys what are the requirements when it comes to suspend. Some PHYs are inherently quirky and need some of the quirky flags dwc3 provides. Note that disabling suspend completely is a pretty large hammer that should only be used if nothing else helps. Some PHYs are happy with a simple delay of U1/U2/U3 entry but, again, check with your Silicon Validation folks, likely they have already gone through this during chip characterization. cheers -- balbi
Attachment:
signature.asc
Description: PGP signature
