回复: [PATCH V2 4/4] usb: dwc3: core: improve reset sequence
Alice Guo (OSS)
alice.guo at oss.nxp.com
Fri Jan 23 08:24:04 CET 2026
> -----邮件原件-----
> 发件人: U-Boot <u-boot-bounces at lists.denx.de> 代表 Marek Vasut
> 发送时间: 2026年1月22日 20:34
> 收件人: Ernest Van Hoecke <ernestvanhoecke at gmail.com>; Chris Morgan
> <macroalpha82 at gmail.com>; Peng Fan (OSS) <peng.fan at oss.nxp.com>; Alice
> Guo <alice.guo at nxp.com>
> 抄送: u-boot at lists.denx.de; thinhn at synopsys.com;
> neil.armstrong at linaro.org; quic_varada at quicinc.com;
> felipe.balbi at linux.intel.com; mkorpershoek at kernel.org; lukma at denx.de;
> trini at konsulko.com; macromorgan at hotmail.com; Thinh Nguyen
> <Thinh.Nguyen at synopsys.com>; Mian Yousaf Kaukab
> <yousaf.kaukab at intel.com>
> 主题: Re: [PATCH V2 4/4] usb: dwc3: core: improve reset sequence
>
> On 1/22/26 1:15 PM, Ernest Van Hoecke wrote:
> > On Thu, Jan 15, 2026 at 05:01:35PM -0600, Chris Morgan wrote:
> >> From: Chris Morgan <macromorgan at hotmail.com>
> >>
> >> According to Synopsys Databook, we shouldn't be relying on
> >> GCTL.CORESOFTRESET bit as that's only for debugging purposes.
> >> Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.
> >>
> >> Host side block will be reset by XHCI driver if necessary. Note that
> >> this reduces amount of time spent on dwc3_probe() by a long margin.
> >>
> >> We're still gonna wait for reset to finish for a long time (default
> >> to 1ms max), but tests show that the reset polling loop executed at
> >> most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
> times
> >> in a row).
> >>
> >> Note that this patch was submitted to Linux in 2016 [1], however I
> >> can confirm it is needed to support gadget mode in U-Boot on my device.
> >> While I am referencing this patch from Linux I am in fact taking the
> >> full existing dwc3_core_soft_reset() function from Linux as it exists
> >> in v6.19-rc5, so it may differ slightly from the information in the
> >> 2016 patch.
> >>
> >> [1]
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/pa
> >> tch/drivers/usb/dwc3?id=f59dcab176293b646e1358144c93c58c3cda2813
> >>
> >
> > Hi Chris,
> >
> > Thanks for your work here. We also have issues with gadget mode on the
> > iMX95 DWC3 IP, noticed on our Aquila iMX95 SoM. This patch series
> > fixes our issues, but only with a small change:
> >
> >> - mdelay(100);
> >> + dev_warn(dwc->dev, "DWC3 controller soft reset failed.\n");
> >> + return -ETIMEDOUT;
> >>
> >> - /* After PHYs are stable we can take Core out of reset state */
> >> - reg = dwc3_readl(dwc->regs, DWC3_GCTL);
> >> - reg &= ~DWC3_GCTL_CORESOFTRESET;
> >> - dwc3_writel(dwc->regs, DWC3_GCTL, reg);
> >> +done:
> >> + /*
> >> + * 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))
> >> + mdelay(50);
> >
> > On the iMX95 I also need this delay to get everything functional. If I
> > remove the conditional version check here, it works well.
> > 'dwc->revision' is 0x5533330B.
> >
> > Is anyone aware of the DWC3 requirements on the iMX95?
> Likely Alice or Peng.
Hi Ernest,
Thank you for your feedback on i.MX95.
I tested this patch series on the i.MX95 19x19 EVK board with USB SDP boot over the USB3 interface, and it works correctly without the additional delay.
The Universal Serial Bus 3.0 Controller on i.MX95 does not need this delay in my testing. Could you please verify that the Universal Serial Bus 3.0 PHY is configured correctly in your setup?
Best regards,
Alice Guo
More information about the U-Boot
mailing list