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 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. 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. 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. Regards Claus
