Re: Options for forcing dwc3 gadget to only accept superspeed

[Felipe Balbi <balbi@kernel.org>]

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


Hi,

Claus Stovgaard <claus.stovgaard@gmail.com> writes:
> On ons, 2020-05-13 at 10:34 +0300, Felipe Balbi wrote:
>> 
>> If it's "ending in super-speed" this means it tried RX.Detect and it
>> failed, thus falling back to high-speed. It's likely that the signal
>> quality in your setup has degraded or is, at least, sub-par.
>> 
>> Forcing a SS-only setup would just give you a device that doesn't
>> even
>> enumerate in some cases.
>> 
>> Could you capture dwc3 tracepoints of the problem?
>> 
>> Also, which kernel version are you running? Which platform?
>> 
>
> Thanks for you reply Balbi.
>
> Will start with from the back. The kernel is 4.19 in the xilinx version
> - https://github.com/Xilinx/linux-xlnx

4.19 is *really* old. Care to try v5.6 or, better yet, v5.7-rc5?

> It is running on a ZynqMP from Xilinx, where we are using the build in
> Cirrus SERDES as phy. In front of the phy is a tusb1042i redriver/mux
> and a Cypress CCG4 as type-c controller for handling the redriver/mux.
>
> Regarding signal integrity - it is on my radar. I know from experience
> that noise on the GND in the cable can highly influence signal
> integrity on the super speed pair in some situations, even though it is
> shielded.

Yeah, common problem with high-speed signals.

> I am currently working on a setup with a Beagle USB analyzer, together
> with dwc3 tracepoints, and automatically disconnect and connect the
> USB. Would like to have both the USB analyzer version of what happening
> on the bus, together with the dwc3 handling.

That makes sense to me. One thing you can try is disabling PHY suspend
(see our existing quirk flags) and also disabling scrambling for
testing. Do NOT, however, ship your product with scrambling disabled ;-)

> It just takes some time to create this test setup (need to do some
> python code for controlling the Beagle and the device), so it will take
> some time before I can have any data. 
>
> So my email is also kind of an brainstorm for what kind of options
> there exist in the dwc3 to control how it falls back to high-speed.

falling back to high-speed is not something we can control. It's part of
the standard, and as such, implemented entirely in the HW. What we can
do is figure out *why* Rx.Detect fails and causes the link to downgrade.

A look at the tracepoints, even without the sniffer, may give us hints
of what's possibly happening.

-- 
balbi

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