On Wed, 27 Jun 2012, Russ Dill wrote:

From: Russ Dill <redacted>

'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0) fixes
an issue where the ULPI PHYs were not held in reset while initializing
the EHCI controller. However, it also changes behavior in
omap-usb-host.c omap_usbhs_init by releasing reset while the
configuration in that function was done.

This change caused a regression on BB-xM where USB would not function
if 'usb start' had been run from u-boot before booting. A change was
made to release reset a little bit earlier which fixed the issue on
BB-xM and did not cause any regressions on 3430 sdp, the board for
which the fix was originally made.

This new fix, 'USB: EHCI: OMAP: Finish ehci omap phy reset cycle
before adding hcd.', (3aa2ae74) caused a regression on OMAP5.

The original fix to hold the EHCI controller in reset during
initialization was correct, however it appears that changing
omap_usbhs_init to not hold the PHYs in reset during it's
configuration was incorrect. This patch first reverts both fixes, and
then changes ehci_hcd_omap_probe in ehci-omap.c to hold the PHYs in
reset as the original patch had done. It also is sure to incorporate
the _cansleep change that has been made in the meantime.

Tested on Beagleboard xM.

Looking at the result of this patch, there seem to be a few mistakes 
remaining in the probe routine.

If the regulator_get() call fails, the failure is logged but ignored.  
Is that really the right thing to do?

The pm_runtime_get_sync() call occurs before the probe is finished.  
This means that ehci-hcd's resume routine will try to power-up the 
device before its data structures have been initialized.  That can't be 
right.

The "get clocks" section occurs after the call to usb_add_hcd().  This
means the controller will start running before the clock references are
acquired -- so the clocks might still be turned off.  That can't be
right either.

If the clk_get(dev, "utmi_p1_gfclk") call fails, the error path never 
calls usb_remove_hcd().

The "err_add_hcd" pathway never calls usb_put_hcd().

I'm going to resubmit my most recent patch based the current 
ehci-omap.c, but you or someone else will still have to fix these 
problems.

Alan Stern