Hi,
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.
Ok, I will remove the delay in driver.
Patrick