On 11/8/19 10:53 AM, Patrick DELAUNAY wrote: > Hi, Hi,
[...] >>>>> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index >>>>> 51023b0c2c..3086411fc4 100644 >>>>> --- a/drivers/usb/host/dwc2.c >>>>> +++ b/drivers/usb/host/dwc2.c >>>>> @@ -1149,6 +1149,8 @@ static int dwc2_reset(struct udevice *dev) >>>>> return ret; >>>>> } >>>>> >>>>> + reset_assert_bulk(&priv->resets); >>>>> + udelay(2); >>>> >>>> Why is there a 2 uS delay ? >>> >>> I think: no real reason to have 2 us.... >>> >>> It was jus a reasonable time to be sure that the device reset is >>> correctly performed, the reset signal is propagated.... >>> >>> but perhaps that no delay is working... >>> I can test without delay if you prefer... >>> >>> PS: I use the same value than DWC2 gadget driver: >>> Added by my commit c2c74f97afff >> >> Isn't there a way to poll the IP to determine whether the reset completed ? > > It is HW IP reset, the complete state is not available for stm32mp1 reset > controller (RCC). > And the need reset duration of depends on each IP (can't be handle in reset > u-class). If it's a SoC specific delay, it should be in the reset driver. > I check with DWC2 OTG IP expert, and we found in DWC_otg_databook_3.30a.pdf > > t_rst: DWC_otg PHY clock domain reset and AHB hclk domain reset over lap time > (a minimum of 12 cycles of the slowest clock is recommended.) > > In our board, we have 209MHz for AHB frequency... USB phy clock is 48MHz > So freq12 cycles is MIN(57ns, 250ns) < 1us. > > The 2us value seens a over protection. > > I will reduce it to 1us in V2 and I will add comments for. Well, why don't you put this into the reset driver ? Seems to be a more fitting place for this. I don't think every single SoC has the same clock settings. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot