Hi John, >-----Original Message----- >From: John Stultz <john.stultz@xxxxxxxxxx> >Sent: Friday, July 3, 2020 11:46 AM >To: Felipe Balbi <balbi@xxxxxxxxxx> >Cc: Tejas Joglekar <tejas.joglekar@xxxxxxxxxxxx>; Yang Fei ><fei.yang@xxxxxxxxx>; Anurag Kumar Vulisha <anuragku@xxxxxxxxxx>; >YongQin Liu <yongqin.liu@xxxxxxxxxx>; Andrzej Pietrasiewicz ><andrzej.p@xxxxxxxxxxxxx>; Thinh Nguyen <thinhn@xxxxxxxxxxxx>; Linux >USB List <linux-usb@xxxxxxxxxxxxxxx>; Jun Li <lijun.kernel@xxxxxxxxx> >Subject: Re: dwc3 inconsistent gadget connection state? > >On Thu, Jul 2, 2020 at 2:44 PM John Stultz <john.stultz@xxxxxxxxxx> wrote: >> >> I've been tripping over an issue on my HiKey960 where with the usb-c >> gadget cable connected, the gadget code doesn't consistently seem to >> initialize properly. I had rarely seen this behavior previously, but >> more recently it has become more frequent and annoying. >> >> Usually, unplugging and replugging the USB-C cable would get things >> working again (but that's not helpful in test labs). >> >> I annotated a bunch of code trying to understand what was going on and >> I narrowed down the difference in the good and bad case to a dwc3 >> reset interrupts happening after usb_gadget_probe_driver() completes. >> In the good case, we see the reset interrupts, and in the failed case >> we don't. > >So I've kept digging around on this, and started dumping registers at the end >of dwc3_gadget_start() and then dwc3_gadget_pullup() as that still is called >shortly after in both cases. > >The one consistent difference between the working and not working case I >saw was the DWC3_DSTS_COREIDLE bit in the DWC3_DSTS register. > >It seems when we get to gadget_start()/pullup() if the DSTS_COREIDLE bit >isn't on we won't get the reset irq. > >I added a simple timeout loop to pullup() similar to the DSTS_DEVCTRLHLT >loop, but in the failure mode it always times out with COREIDLE not being set. > >Searching around hasn't provided any info on what COREIDLE actually means, >so I'm a bit in the dark. Any clues? > DSTS.CoreIdle bit indicates that the core processed all the RXFIFO data, updated the Descriptors and is in idle state. >From your previous mail I understood that the USB-C connection is configured for USB 2.0 only. Since you are facing issue with reset, can u please try setting the USB2PHYCFG. XCVRDLY bit. Enabling this bit adds an extra 2.5us delay after the controller sending command to configure the ULPI transceiver to HS mode and controller driving TxValid to 0, for sending a HS chirp signal. Please check if this workaround works for you. Thanks, Anurag Kumar Vulisha
