Re: dwc3 inconsistent gadget connection state?

[Felipe Balbi <balbi@kernel.org>]

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


Hi,

John Stultz <john.stultz@linaro.org> writes:
> On Sat, Jul 4, 2020 at 7:38 AM Felipe Balbi <balbi@kernel.org> wrote:
>> 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?
>
> Correct. The only way to get it working is to unplug and replug the
> cable (sometimes more than once).
>
>> 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.
>
> Here's a diff of the regdump in bad and good cases:
> --- regdump.bad 2020-07-07 03:44:46.799514793 +0000
> +++ regdump.good        2020-07-07 03:44:44.723534198 +0000
> @@ -162,29 +162,29 @@
>  GEVNTSIZ(0) = 0x00001000
>  GEVNTCOUNT(0) = 0x00000000
>  GHWPARAMS8 = 0x00000fea
> -DCFG = 0x00120804
> -DCTL = 0x80f00000
> +DCFG = 0x0052082c

the only interesting thing here is DCFG. Can you decode it?

> +DCTL = 0x8cf00a00

IIRC, this is only telling you that your controller is in U0 or
something like that. Not interesting.

>> 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.
>
> Unfortunately I don't have any access to silicon validation folks.

no publicly available Errata List either? Do you know which PHY IP this
platform uses?

> There is already a number of the quirk bindings in use, but I'll
> tinker around with them a bit to see if it causes any behavior change.

Would be great to review those with people who were involved with the
actual Silicon development, but if you don't have access to them, the
discussion is moot :-s

> Thanks so much for the ideas and feedback! Much appreciated!

no worries ;-)

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]