Re: dwc3 inconsistent gadget connection state?

[Felipe Balbi <balbi@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]


Hi,

John Stultz <john.stultz@linaro.org> writes:
> On Fri, Jul 3, 2020 at 2:54 AM Felipe Balbi <balbi@kernel.org> wrote:
>> John Stultz <john.stultz@linaro.org> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]