kernel hang when initializing usb

[Rao, Ravi]

Hi Tony/Greg/Liu,
    I'am Ravi working on a P2040 based custom board which has a compact flash connected to USB port via CYPRESS USB to IDE bridge. I am able to see the USB mass storage device from uboot but when I boot to kernel it hangs.
Below is the dump that shows the part where it hangs. I have added some debug prints and narrowed down that the hang happens when it is trying to write to port status(portsc) register.

>>>>>
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: Before invoking reset
ehci_fsl_setup got invoked..
Before invoking ehci_readl
Before invoking ehci_halt
ehci_writel invoked with val=0x0, reg=0xf125e148
Before invoking ehci_init
Before invoking ehci_reset
ehci_writel invoked with val=0x80002, reg=0xf125e140
ehci_writel invoked with val=0x3, reg=0xf125e1a8
Before invoking ehci_fsl_reinit
Entering ehci_fsl_usb_setup with op_mode=0x1 have_sysif_regs=0x1
Completed SNOOPing of 4GB space
Before invoking ehci_fsl_setup_phy with phy_mode=0x2
Entering ehci_fsl_setup_phy, portsc=0x0 port_offset=0x0 port_status_addr=0xf125e184
Before invoking mdelay, cntrlr_ver=0x1
Before invoking ehci_writel, portsc=0x0 port_offset=0x0 port_status_addr=0xf125e184
ehci_writel invoked with val=0x0, reg=0xf125e184
>>>>>>


Kernel I am using is Linux version 3.0.51-rt75 and it looks like it has all the required patches described in the thread(http://thread.gmane.org/gmane.linux.usb.general/58763/focus=58795) but I still see the hang.
Can one you give some pointers to troubleshoot what may be causing this hang
Below is the email in which Tony had mentioned that he is also seeing the hang even after applying all the prescribed patches.
Tony were you able to find the cause for the hang ? If so can you please share what was the fix that you made.

>>>>
Re: [ 011/108] powerpc/usb: fix bug of kernel hang when initializing usb Remove Highlighting [In reply to]
Greg KH <gregkh [at] linuxfoundation> writes:

> 3.0-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Shengzhou Liu <Shengzhou.Liu [at] freescale>
>
> commit 28c56ea1431421dec51b7b229369e991481453df upstream.
>
> If USB UTMI PHY is not enable, writing to portsc register will lead to
> kernel hang during boot up.

I apologize for the late response, but I was encountering this same
hang (on an 8315) and applied this patch. (For what it's worth, I'm
only seeing it after many warm boots; a cold boot / hard power cycle
solves the issue, but since this is eventually going to be locked up
in a box without a console...)

I encountered the hang again this evening, so this fix (plus the snoop
fix) is not sufficientl

Reading through the original thread, it seems that an additional delay
might be required:

http://article.gmane.org/gmane.linux.usb.general/58795

> First, the SDK kernel had a delay after setting that bit, I added
> that back in. This is not what fixed it but it looks like the
> right thing to do, though please, use msleep rather than udelay
> here if possible (not in atomic context).

However, I never saw a patch to that effect. I'm assuming (hoping!)
it's something as simple as:

------------------------------------------------------------------------
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 09fd214..d58c1c6 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -236,6 +236,7 @@ static void ehci_fsl_setup_phy(struct ehci_hcd *ehci,
case FSL_USB2_PHY_UTMI:
/* enable UTMI PHY */
setbits32(non_ehci + FSL_SOC_USB_CTRL, CTRL_UTMI_PHY_EN);
+ msleep(5);
portsc |= PORT_PTS_UTMI;
break;
case FSL_USB2_PHY_NONE:
------------------------------------------------------------------------

But confirmation would be nice. Also, which SDK kernel was this
compared against? I just downloaded the 8315ERDB BSP, and the kernel
there doesn't seem to have any of this in it.

There was also the follow-on patch that enabled snooping (to deal with
cache coherency?):

http://article.gmane.org/gmane.linux.usb.general/58798

(If there was a formal patch there, it looks like it got scrambled on
gmane, and I can't find another list archive.)

Is that also needed for consistent results here? (Or are we wandering
astray from "-stable" material?)

Thanks,
Tony.
>>>>

Thanks & Regards,
Ravi..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20130711/dee3abdd/attachment-0001.html>