Re: [U-Boot] [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue

On 05/04/12 12:06, Russ Dill wrote:
On Thu, May 3, 2012 at 11:03 PM, Igor Grinberg grinberg@compulab.co.il wrote:
Hi Russ,
On 05/03/12 22:08, Russ Dill wrote:
On Wed, May 2, 2012 at 3:38 AM, Raja, Govindraj govindraj.raja@ti.com wrote:
On Wed, May 2, 2012 at 2:17 PM, Russ Dill Russ.Dill@ti.com wrote:
On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.raja@ti.com wrote:
On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgowda@ti.com wrote: > From: Keshava Munegowda Keshava_mgowda@ti.com > > It is observed that the echi ports of 3430 sdp board > are not working due to the random timing of programming > the associated GPIOs of the ULPI PHYs of the EHCI for reset. > If the PHYs are reset at during usbhs core driver, host ports will > not work because EHCI driver is loaded after the resetting PHYs. > The PHYs should be in reset state while initializing the EHCI > controller. > The code which does the GPIO pins associated with the PHYs > are programmed to reset is moved from the USB host core driver > to EHCI driver.
I tested on beagle xm where gpio nreset is requested from board file. (Basic enumertaion after gpio nreset seems to work fine, Hub and smsc lan chip get detected afetr boot up)
What base did you test this on top of? my xM is failing USB-wise when I apply this on v3.3.3 (with the UART mux fix patch) and where it is applied within master (3.4-rc4, again, with the UART mux fix patch). Additionally, reverting this patch from 3.4-rc5 causes rc5 to work properly.
Works for me be on 3.4-rc5 Beagle-XM even without reverting the patch
Logs as in here [1].
-- Thanks, Govindraj.R
I've tracked down the difference. I'm loading my uEnv.txt and uImage in u-boot from the network which means initializing USB. You are loading straight from MMC. If I switch to loading straight from MMC everything works.
Can everyone do a 'usb start' in u-boot before booting and re-test? I'm pretty sure this is a regression, but the bug could be a strange u-boot/kernel interaction.
Probably, kernel code does not reinitialize EHCI correctly if it was already enabled? Can you try the below sequence: usb start usb stop boot Linux
That doesn't work. Rebooting does work though.
This means that U-Boot's usb stop command is also not clean enough... So we have two problems here, one is related to kernel USB initialization and the second to U-Boot usb stop command...
participants (1)
-
Igor Grinberg