[PATCH v2 2/7] drivers: usb: dwc3: Add delay after core soft reset

[Sumit Garg]

On Wed, Dec 24, 2025 at 11:26:12AM +0530, Balaji Selvanathan wrote:
> 
> On 12/23/2025 2:35 PM, Sumit Garg wrote:
> > On Mon, Nov 24, 2025 at 09:24:58PM +0530, Balaji Selvanathan wrote:
> > > Add a 100 ms delay after clearing the core soft reset bit to ensure
> > > the DWC3 controller has sufficient time to complete its reset
> > > sequence before subsequent register accesses.
> > > 
> > > Without this delay, USB initialization can fail on some Qualcomm
> > > platforms, particularly when using super-speed capable PHYs like
> > > the QMP USB3-DP Combo PHY on SC7280/QCM6490.
> > > 
> > > The change is taken from following upstream Linux implementation:
> > > https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/dwc3/core.c?id=f88359e1588b85cf0e8209ab7d6620085f3441d9
> > If I understand correctly the kernel change here especially following
> > comment:
> > 
> > 	/*
> > 	 * Wait for internal clocks to synchronized. DWC_usb31 and
> > 	 * DWC_usb32 may need at least 50ms (less for DWC_usb3). To
> > 	 * keep it consistent across different IPs, let's wait up to
> > 	 * 100ms before clearing GCTL.CORESOFTRESET.
> > 	 */
> > 
> > the delay is required before clearing GCTL.CORESOFTRESET and not after
> > which your change seems to do. Also, here we aren't doing any role
> > switch too, right?
> 
> Hi Sumit,
> 
> You're correct about the Linux implementation. However, in U-Boot's case,
> the context is different:
> 
> 1. Linux: The delay is during role switching in dwc3_set_mode(), where only
> GCTL.CORESOFTRESET is toggled.
> 
> 2. U-Boot: The delay is in dwc3_core_soft_reset() during initial boot, which
> has a more complex sequence:
> 
>    - Sets GCTL.CORESOFTRESET
>    - Asserts PHY resets (USB2/USB3)
>    - Waits 100ms
>    - Clears PHY resets
>    - Waits 100ms (for PHY stabilization)
>    - Clears GCTL.CORESOFTRESET
> The additional delay after clearing the reset bit is needed in U-Boot to
> ensure the controller is fully operational before subsequent register
> accesses, particularly for super-speed PHYs on QCM6490/SC7280. Otherwise,
> fastboot mode is not working sometimes (stability issue).
>

I would rather suggest you to explore following kernel driver init
sequence:

dwc3_core_init() ->
  dwc3_core_soft_reset()

and see if you can have a better explanation for the delay requirement
here similar to following quote:

        /*
         * For DWC_usb31 controller 1.80a and prior, once DCTL.CSFRST bit
         * is cleared, we must wait at least 50ms before accessing the PHY
         * domain (synchronization delay).
         */
        if (DWC3_VER_IS_WITHIN(DWC31, ANY, 180A))
                msleep(50);

> Would you be okay with adding this delay after clearing GCTL.CORESOFTRESET?

Adding random delays in the common code may have impact on boot times
for all the platforms. We really should understand the root cause here
in case if this delay requirement is specific to a particular DWC
controller version or not?

And since your problem relates to DWC controller operating in device
mode, so you should focus on the gaps you see with corresponding kernel
driver device mode init sequence. As the kernel driver has been well
supported on Qcom platforms with adb working fine in user-space.

-Sumit

> 
> Regards,
> 
> Balaji
> 
> > 
> > -Sumit
> > 
> > > Signed-off-by: Balaji Selvanathan <balaji.selvanathan at oss.qualcomm.com>
> > > ---
> > > v2:
> > > - Gave correct commit id for linux implementation
> > > ---
> > >   drivers/usb/dwc3/core.c | 2 ++
> > >   1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> > > index 847fa1f82c3..ff0bca0dd8e 100644
> > > --- a/drivers/usb/dwc3/core.c
> > > +++ b/drivers/usb/dwc3/core.c
> > > @@ -94,6 +94,8 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
> > >   	reg &= ~DWC3_GCTL_CORESOFTRESET;
> > >   	dwc3_writel(dwc->regs, DWC3_GCTL, reg);
> > > +	mdelay(100);
> > > +
> > >   	return 0;
> > >   }
> > > -- 
> > > 2.34.1
> > >