Hi John,
Am Mittwoch, 7. September 2016, 19:39:43 CEST schrieb John Youn:
> When a force mode bit is set and the IDDIG debounce filter is enabled,
> there is a delay for the forced mode to take effect. This delay is due
> to the IDDIG debounce filter and is variable depending on the platform's
> PHY clock speed. To account for this delay we can poll for the expected
> mode.
>
> On a clear force mode, since we don't know what mode to poll for, delay
> for a fixed 100 ms. This is the maximum delay based on the slowest PHY
> clock speed.
>
> Tested-by: Stefan Wahren <stefan.wahren at i2se.com>
> Signed-off-by: John Youn <johnyoun at synopsys.com>
> ---
[...]
> @@ -475,12 +478,6 @@ void dwc2_force_dr_mode(struct dwc2_hsotg *hsotg)
> __func__, hsotg->dr_mode);
> break;
> }
> -
> - /*
> - * NOTE: This is required for some rockchip soc based
> - * platforms.
> - */
> - msleep(50);
> }
sorry for not finding the time to test your subsequent versions, but this still
acts up on my Rockchip boards, as I'm still running into errors like
[ 4.875570] usb usb2-port1: connect-debounce failed
And it still requires the 50ms default sleep to work properly. But it seems I
was able to find some interesting things when testing the individual parts of
your patch. The port that is affected is a host-only port, so I can also get
[ 3.862440] dwc2 101c0000.usb: dwc2_force_dr_mode() to mode 1
{custom debug in dwc2_force_dr_mode}
[ 3.868223] dwc2 101c0000.usb: dwc2_force_mode() no OTG controller
{custom debug in dwc2_force_mode at if (!dwc2_hw_is_otg) }
I remember that I also did my previous tests on the host-only ports (since the
otg ones are often also used as power-supply) but sadly I only have remote
access to my boards this week, so cannot change the cabling to actually try
with a real otg dwc2.
Heiko
