On Thu, 2019-04-25 at 13:11 -0700, Rob Weber wrote: > Hi Everyone, > > On Wed, Apr 24, 2019 at 02:33:48PM -0400, Alan Stern wrote: > > > > On Wed, 24 Apr 2019, Claus H. Stovgaard wrote: > > > > > > > > Hi Balbi and other USB developers. > > > > > > I am developing camera devices based on Xilinx ZynqMP, using the > > > gadget framework and the build-in dwc3 core of the ZynqMP as USB3 > > > controller and the build-in Cirrus SERDES as phy. > > > Testing with a number of hosts and Windows 7, has shown sporadic > > > reconnects when leaving U2/U1, caused by failing link training, > > > where > > > the host resets the bus. Sometime it also means it reconnect via > > > USB2. > > > > > > So to overcome this, I will like to have the option for disabling > > > U1/U2 on the core when working with those hosts. > > > > > > Currently I have made a hack in ep0.c where I return EINVAL in > > > dwc3_ep0_handle_u1 and dwc3_ep0_handle_u2 together with not > > > setting > > > DWC3_DCTL_ACCEPTU1ENA and DWC3_DCTL_ACCEPTU2ENA in > > > dwc3_ep0_set_config > > > Will though prefer a solution possible to upstream, so was > > > thinking > > > about adding two devicetree bindings. > > > > > > * snps,u1_disable_as_gadget: When set the core will not enable U1 > > > if > > > requested from host, nor initiate U1. > > > * snps,u2_disable_as_gadget: When set the core will not enable U2 > > > if > > > requested from host, nor initiate U2. > > > > > > If you think this might be something which can be upstreamed I > > > will > > > prepare the code and send a patch for discussion. > > > On the other hand, if you think that disabling U1/U2 via device > > > tree > > > as suggested should not be a feature no need for me to try making > > > it > > > a feature. > > Speaking as an interested bystander, I would first wonder why your > > hardware fails during link training. If it is properly designed, > > that > > should not happen. The fact that it does happen suggests your > > devices > > might also experience problems during normal data transport. > I was recently debugging a similar problem where my device would > improperly transition from U2 to U0. This caused the connection to > reset > and the device to be re-enumerated as a USB2 device. Our design uses > an > Intel CherryTrail z8550 SoC that has an internal dwc3 USB device > controller. I worked with Felipe a couple of weeks ago [1] to come up > with > the same workaround you mentioned above. I disable device-initiated > U1/U2 > in ep0_set_config and also return -EINVAL when handling SetFeature > requests from the USB host. I've attached my patch for kernel 4.9.115 > below for reference. > > Although we have applied this workaround, we still have not > identified a > root cause of the issue. Intel has no known errata related to the > symptoms > we are experiencing. We've done quite a bit of analysis on our design > and > are pretty confident we've followed all design guidelines for USB. > > Cheers, > Rob Weber > > [1] https://marc.info/?t=155349935600001&r=1&w=2 Thanks for this info, reading through your thread and can see many similarities. FYI we are also using a Type-C interface (Using the Cypress CCG4 as controller), and using a redriver / mux. We are using the tusb1042i Have previously asked for information from Xilinx for the dwc3 core (the synopsys documentation), and info regarding the PHY. The serdes module used as phy is pretty undocumented in the Xilinx documentation, with many registers left undocumented. Please keep me posted if you find the root cause for your problem, and I will do the same. /Claus
