Hi, Michael Grzeschik <mgr@xxxxxxxxxxxxxx> writes: > On Tue, Dec 15, 2020 at 12:24:51PM +0530, Manish Narani wrote: >>Add a new driver for supporting Xilinx platforms. This driver is used >>for some sequence of operations required for Xilinx USB controllers. >>This driver is also used to choose between PIPE clock coming from SerDes >>and the Suspend Clock. Before the controller is out of reset, the clock >>selection should be changed to PIPE clock in order to make the USB >>controller work. There is a register added in Xilinx USB controller >>register space for the same. > > I tried out this driver with the vanilla kernel on an zynqmp. Without > this patch the USB-Gadget is already acting buggy. In the gadget mode, > some iterations of plug/unplug results to an stalled gadget which will > never come back without a reboot. > > With the corresponding code of this driver (reset assert, clk modify, > reset deassert) in the downstream kernels phy driver we found out it is > totaly stable. But using this exact glue driver which should do the same > as the downstream code, the gadget still was buggy the way described > above. > > I suspect the difference lays in the different order of operations. > While the downstream code is runing the resets inside the phy driver > which is powered and initialized in the dwc3-core itself. With this glue > layser approach of this patch the whole phy init is done before even > touching dwc3-core in any way. It seems not to have the same effect, > though. > > If really the order of operations is limiting us, we probably need > another solution than this glue layer. Any Ideas? might be a good idea to collect dwc3 trace events. Can you do that? -- balbi
