On Wed, 27 Jun 2012, Russ Dill wrote: > From: Russ Dill <Russ.Dill@xxxxxxxxx> > > '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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
