[U-Boot] [RESEND PATCH 3/5] usb: host: dwc2: force reset assert

[Marek Vasut]

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.