Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
Hi Russ, On 05/03/12 22:08, Russ Dill wrote: On Wed, May 2, 2012 at 3:38 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@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 [1]: http://pastebin.pandaboard.org/index.php/view/20343533 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 ? -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Thu, May 3, 2012 at 11:03 PM, Igor Grinberg grinb...@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.r...@ti.com wrote: On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@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 [1]: http://pastebin.pandaboard.org/index.php/view/20343533 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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [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 grinb...@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.r...@ti.com wrote: On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@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 [1]: http://pastebin.pandaboard.org/index.php/view/20343533 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... -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Thu, May 3, 2012 at 6:55 AM, Russ Dill russ.d...@ti.com wrote: On Wed, May 2, 2012 at 3:38 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@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]. I've compared the boot logs and modified some configuration options and command line parameters to make them match, but still no dice. Can you send me your .config? I have uploaded the .config + my binaries (MLO +u-boot +uimage with initramfs) available here [1] -- Thanks, Govindraj.R [1]: http://www.sendspace.com/file/g7m58r -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Wed, May 2, 2012 at 3:38 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@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 [1]: http://pastebin.pandaboard.org/index.php/view/20343533 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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
Op 2 mei 2012, om 10:47 heeft Russ Dill het volgende geschreven: [0.198272] omap-mcbsp.3: alias fck already exists [3.461212] clock: dpll1_ck failed transition to 'locked' What's happening in those 3.3 seconds? regards, Koen -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@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 [1]: http://pastebin.pandaboard.org/index.php/view/20343533 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
Op 2 mei 2012, om 12:38 heeft Raja, Govindraj het volgende geschreven: On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@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]. From your log: [1.705291] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [3.726593] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller Why is the ehci stuff taking more than 2 seconds? regards, Koen-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Wed, May 2, 2012 at 4:20 PM, Koen Kooi k...@dominion.thruhere.net wrote: Op 2 mei 2012, om 12:38 heeft Raja, Govindraj het volgende geschreven: On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@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]. From your log: [ 1.705291] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 3.726593] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller Why is the ehci stuff taking more than 2 seconds? phy reset operation in omap_ehci_soft_phy_reset failing and timing out. -- Thanks, Govindraj.R -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Wed, May 2, 2012 at 3:38 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@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]. I've compared the boot logs and modified some configuration options and command line parameters to make them match, but still no dice. Can you send me your .config? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@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. 3.4-rc5 with 1fcb57d0f6e11 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' reverted: ## Booting kernel from Legacy Image at 8020 ... Image Name: Linux-3.4.0-rc5-ktest-1-g433 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3398392 Bytes = 3.2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.4.0-rc5-ktest-1-g433e357 (russ@russ-laptop) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #92 SMP Wed May 2 01:39:19 MST 2012 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP3 Beagle Board [0.00] Reserving 25165824 bytes SDRAM for VRAM [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz [0.00] PERCPU: Embedded 8 pages/cpu @c101b000 s11520 r8192 d13056 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 123648 [0.00] Kernel command line: tty1 console=tty0 console=ttyO2,115200n8 consoleblank=0 mpurate=100 vram=24M omapfb.mode=hd720 omapfb.vram=0:8M,1:4M,2:4M root=/dev/mmcblk0p2 ip=off rw rootwait [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 487MB = 487MB total [0.00] Memory: 481768k/481768k available, 42520k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xe080 - 0xff00 ( 488 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc05dd28c (5973 kB) [0.00] .init : 0xc05de000 - 0xc062bd00 ( 312 kB) [0.00] .data : 0xc062c000 - 0xc06bdb58 ( 583 kB) [0.00].bss : 0xc06bdb7c - 0xc0c12060 (5458 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:474 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER12 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] Console: colour dummy device 80x30 [0.00] console [tty0] enabled [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.003601] Calibrating delay loop... 515.72 BogoMIPS (lpj=2015232) [0.074249] pid_max: default: 32768 minimum: 301 [0.074981] Security Framework initialized [0.075256] Mount-cache hash table entries: 512 [0.080139] CPU: Testing write buffer coherency: ok [
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
Hi Samuel, On 04/16/12 19:46, Samuel Ortiz wrote: Hi Keshava, On Wed, Apr 11, 2012 at 05:15:03PM +0530, Munegowda, Keshava wrote: On Tue, Mar 27, 2012 at 8:40 PM, Igor Grinberg grinb...@compulab.co.il wrote: On 03/19/12 08:42, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@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. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Both EHCI ports worked on cm-t3730 previously and no regression is seen with this patch. Tested-by: Igor Grinberg grinb...@compulab.co.il -- Regards, Igor. Hi sameo Since I am not seeing this patch in linux-next labled 3.4.rc2 on 10th april 2012; please let me know your plan to queue this patch for the main line. I applied this one to my for-linus branch, thanks. Since, you have already applied this patch to your tree, can you please take also the [1] patch? It has ackes from Felipe and Alan and depends on the patch in subj. Thanks [1] http://www.spinics.net/lists/linux-omap/msg67253.html -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Mon, Apr 16, 2012 at 10:16 PM, Samuel Ortiz sa...@linux.intel.com wrote: Hi Keshava, On Wed, Apr 11, 2012 at 05:15:03PM +0530, Munegowda, Keshava wrote: On Tue, Mar 27, 2012 at 8:40 PM, Igor Grinberg grinb...@compulab.co.il wrote: On 03/19/12 08:42, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@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. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Both EHCI ports worked on cm-t3730 previously and no regression is seen with this patch. Tested-by: Igor Grinberg grinb...@compulab.co.il -- Regards, Igor. Hi sameo Since I am not seeing this patch in linux-next labled 3.4.rc2 on 10th april 2012; please let me know your plan to queue this patch for the main line. I applied this one to my for-linus branch, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ Thank a lot Samuel regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
Hi Keshava, On Wed, Apr 11, 2012 at 05:15:03PM +0530, Munegowda, Keshava wrote: On Tue, Mar 27, 2012 at 8:40 PM, Igor Grinberg grinb...@compulab.co.il wrote: On 03/19/12 08:42, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@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. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Both EHCI ports worked on cm-t3730 previously and no regression is seen with this patch. Tested-by: Igor Grinberg grinb...@compulab.co.il -- Regards, Igor. Hi sameo Since I am not seeing this patch in linux-next labled 3.4.rc2 on 10th april 2012; please let me know your plan to queue this patch for the main line. I applied this one to my for-linus branch, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Tue, Mar 27, 2012 at 8:40 PM, Igor Grinberg grinb...@compulab.co.il wrote: On 03/19/12 08:42, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@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. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Both EHCI ports worked on cm-t3730 previously and no regression is seen with this patch. Tested-by: Igor Grinberg grinb...@compulab.co.il -- Regards, Igor. Hi sameo Since I am not seeing this patch in linux-next labled 3.4.rc2 on 10th april 2012; please let me know your plan to queue this patch for the main line. Thanks and Regards Keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Felipe, Samuel, On 03/20/12 17:55, Felipe Balbi wrote: On Tue, Mar 20, 2012 at 04:53:53PM +0100, Samuel Ortiz wrote: Hi Keshava, On Mon, Mar 19, 2012 at 12:12:47PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@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. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Felipe, are you ok with that patch ? I'll most likely queue it after this merge window is closed though. I've just sent a patch that depends on this one (ehci-omap.c part), though it needs a review, but Samuel, you still haven't applied/pushed the patch to your git.kernel.org, so can this one go through Felipe's tree to minimize the dependencies/conflicts? What do you think, Felipe? my bad, here's my Ack: Acked-by: Felipe Balbi ba...@ti.com - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPccxIAAoJEBDE8YO64Efay3EP/ji+LEF3rDCDkqpZ9ELYcsWW My+4EozWSXRHEpxFk/xb9V/3+inX9cczaRR3DRFQLn8UxxTtn0VJSVmTtFB4Uadc vsrlBU9gi6DXYX1Jpu3vRUvLnQcfBzlXCnLTVW3fgsYyztNHcHQj7F87t/Kug5V1 UFV21DNzePYlta3+UZly8q0anqvEqlbTY0j81pWhpL5i0T/8iGAhWdTOppbgT+oH FZ7W+YUk1TJtKHwFWABXfAIBwg/NHaIYPKDiv8z3wIFnT2Lk5IdZagIZfwYExtUE spX2DEMtti8yKwfEJW2rQHLF8/YCWxKc9oiYegVWniNx7WBYje2wEKP1lT4eYJbe iCPzhPu63wipvaw2yaVYFdJ6fCHZ4s8ZkE2fWhuGgSsnD/4ljAtl0i+eeVhu6fdi kQF6E3uNOVOSh3iI1GuMUjolOVDAQiRZdQGDATstLu38sC2NVPfmxW6z6doSQcn5 TeiCkIiZaC/b+6gvglBbbWuxcNUJQCJ+2DFVweBEDmmO2WKgpgo6GGhE0H4uMxjs 1wSP6EABz6O2ihjq1YlBvXMvhP2YWO68u/iBVty1cIt5u9mOFnavpNMPLj9c02ew AE8TM9LLS5zOYQtEYU3q0WiGQEhaSa5f87pEdQYDH0i98FH9prRRxl3Zh0IOhHa8 Skz7J4AVgxdEci8Op1Uc =oe1q -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
Hi Igor, On Tue, Mar 27, 2012 at 04:18:49PM +0200, Igor Grinberg wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Felipe, Samuel, On 03/20/12 17:55, Felipe Balbi wrote: On Tue, Mar 20, 2012 at 04:53:53PM +0100, Samuel Ortiz wrote: Hi Keshava, On Mon, Mar 19, 2012 at 12:12:47PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@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. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Felipe, are you ok with that patch ? I'll most likely queue it after this merge window is closed though. I've just sent a patch that depends on this one (ehci-omap.c part), though it needs a review, but Samuel, you still haven't applied/pushed the patch to your git.kernel.org, so can this one go through Felipe's tree to minimize the dependencies/conflicts? Once (and if) Linus pulls from my for-next branch, I'll start taking patches again. It's a matter of days, so you can either wait for me to apply this patch or have Felipe taking both. I'm fine either ways. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On 03/19/12 08:42, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@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. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Both EHCI ports worked on cm-t3730 previously and no regression is seen with this patch. Tested-by: Igor Grinberg grinb...@compulab.co.il -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Tue, Mar 20, 2012 at 9:25 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Mar 20, 2012 at 04:53:53PM +0100, Samuel Ortiz wrote: Hi Keshava, On Mon, Mar 19, 2012 at 12:12:47PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@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. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Felipe, are you ok with that patch ? I'll most likely queue it after this merge window is closed though. my bad, here's my Ack: Acked-by: Felipe Balbi ba...@ti.com -- balbi thanks , Felipe regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
Hi Keshava, On Mon, Mar 19, 2012 at 12:12:47PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@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. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Felipe, are you ok with that patch ? I'll most likely queue it after this merge window is closed though. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Tue, Mar 20, 2012 at 04:53:53PM +0100, Samuel Ortiz wrote: Hi Keshava, On Mon, Mar 19, 2012 at 12:12:47PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@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. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Felipe, are you ok with that patch ? I'll most likely queue it after this merge window is closed though. my bad, here's my Ack: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
From: Keshava Munegowda keshava_mgo...@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)
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
Tested-by: Govindraj.R govindraj.r...@ti.com
---
drivers/mfd/omap-usb-host.c | 44
--
drivers/usb/host/ehci-omap.c | 39 +++-
2 files changed, 37 insertions(+), 46 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 68ac2c5..9927129 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -25,7 +25,6 @@
#include linux/clk.h
#include linux/dma-mapping.h
#include linux/spinlock.h
-#include linux/gpio.h
#include plat/usb.h
#include linux/pm_runtime.h
@@ -502,19 +501,6 @@ static void omap_usbhs_init(struct device *dev)
pm_runtime_get_sync(dev);
spin_lock_irqsave(omap-lock, flags);
- if (pdata-ehci_data-phy_reset) {
- if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
- gpio_request_one(pdata-ehci_data-reset_gpio_port[0],
- GPIOF_OUT_INIT_LOW, USB1 PHY
reset);
-
- if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
- gpio_request_one(pdata-ehci_data-reset_gpio_port[1],
- GPIOF_OUT_INIT_LOW, USB2 PHY
reset);
-
- /* Hold the PHY in RESET for enough time till DIR is high */
- udelay(10);
- }
-
omap-usbhs_rev = usbhs_read(omap-uhh_base, OMAP_UHH_REVISION);
dev_dbg(dev, OMAP UHH_REVISION 0x%x\n, omap-usbhs_rev);
@@ -593,39 +579,10 @@ static void omap_usbhs_init(struct device *dev)
usbhs_omap_tll_init(dev, OMAP_TLL_CHANNEL_COUNT);
}
- if (pdata-ehci_data-phy_reset) {
- /* Hold the PHY in RESET for enough time till
- * PHY is settled and ready
- */
- udelay(10);
-
- if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
- gpio_set_value
- (pdata-ehci_data-reset_gpio_port[0], 1);
-
- if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
- gpio_set_value
- (pdata-ehci_data-reset_gpio_port[1], 1);
- }
-
spin_unlock_irqrestore(omap-lock, flags);
pm_runtime_put_sync(dev);
}
-static void omap_usbhs_deinit(struct device *dev)
-{
- struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
- struct usbhs_omap_platform_data *pdata = omap-platdata;
-
- if (pdata-ehci_data-phy_reset) {
- if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
- gpio_free(pdata-ehci_data-reset_gpio_port[0]);
-
- if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
- gpio_free(pdata-ehci_data-reset_gpio_port[1]);
- }
-}
-
/**
* usbhs_omap_probe - initialize TI-based HCDs
@@ -861,7 +818,6 @@ static int __devexit usbhs_omap_remove(struct
platform_device *pdev)
{
struct usbhs_hcd_omap *omap = platform_get_drvdata(pdev);
- omap_usbhs_deinit(pdev-dev);
iounmap(omap-tll_base);
iounmap(omap-uhh_base);
clk_put(omap-init_60m_fclk);
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index bba9850..5c78f9e 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -42,6 +42,7 @@
#include plat/usb.h
#include linux/regulator/consumer.h
#include linux/pm_runtime.h
+#include linux/gpio.h
/* EHCI Register Set */
#define EHCI_INSNREG04 (0xA0)
@@ -191,6 +192,19 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
}
}
+ if (pdata-phy_reset) {
+ if (gpio_is_valid(pdata-reset_gpio_port[0]))
+ gpio_request_one(pdata-reset_gpio_port[0],
+ GPIOF_OUT_INIT_LOW, USB1 PHY
reset);
+
+ if
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Mon, Mar 19, 2012 at 7:04 PM, Raja, Govindraj govindraj.r...@ti.com wrote:
On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
From: Keshava Munegowda keshava_mgo...@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)
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
Tested-by: Govindraj.R govindraj.r...@ti.com
---
drivers/mfd/omap-usb-host.c | 44
--
drivers/usb/host/ehci-omap.c | 39 +++-
2 files changed, 37 insertions(+), 46 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 68ac2c5..9927129 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -25,7 +25,6 @@
#include linux/clk.h
#include linux/dma-mapping.h
#include linux/spinlock.h
-#include linux/gpio.h
#include plat/usb.h
#include linux/pm_runtime.h
@@ -502,19 +501,6 @@ static void omap_usbhs_init(struct device *dev)
pm_runtime_get_sync(dev);
spin_lock_irqsave(omap-lock, flags);
- if (pdata-ehci_data-phy_reset) {
- if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
-
gpio_request_one(pdata-ehci_data-reset_gpio_port[0],
- GPIOF_OUT_INIT_LOW, USB1 PHY
reset);
-
- if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
-
gpio_request_one(pdata-ehci_data-reset_gpio_port[1],
- GPIOF_OUT_INIT_LOW, USB2 PHY
reset);
-
- /* Hold the PHY in RESET for enough time till DIR is high */
- udelay(10);
- }
-
omap-usbhs_rev = usbhs_read(omap-uhh_base, OMAP_UHH_REVISION);
dev_dbg(dev, OMAP UHH_REVISION 0x%x\n, omap-usbhs_rev);
@@ -593,39 +579,10 @@ static void omap_usbhs_init(struct device *dev)
usbhs_omap_tll_init(dev, OMAP_TLL_CHANNEL_COUNT);
}
- if (pdata-ehci_data-phy_reset) {
- /* Hold the PHY in RESET for enough time till
- * PHY is settled and ready
- */
- udelay(10);
-
- if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
- gpio_set_value
- (pdata-ehci_data-reset_gpio_port[0], 1);
-
- if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
- gpio_set_value
- (pdata-ehci_data-reset_gpio_port[1], 1);
- }
-
spin_unlock_irqrestore(omap-lock, flags);
pm_runtime_put_sync(dev);
}
-static void omap_usbhs_deinit(struct device *dev)
-{
- struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
- struct usbhs_omap_platform_data *pdata = omap-platdata;
-
- if (pdata-ehci_data-phy_reset) {
- if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
- gpio_free(pdata-ehci_data-reset_gpio_port[0]);
-
- if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
- gpio_free(pdata-ehci_data-reset_gpio_port[1]);
- }
-}
-
/**
* usbhs_omap_probe - initialize TI-based HCDs
@@ -861,7 +818,6 @@ static int __devexit usbhs_omap_remove(struct
platform_device *pdev)
{
struct usbhs_hcd_omap *omap = platform_get_drvdata(pdev);
- omap_usbhs_deinit(pdev-dev);
iounmap(omap-tll_base);
iounmap(omap-uhh_base);
clk_put(omap-init_60m_fclk);
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index bba9850..5c78f9e 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -42,6 +42,7 @@
#include plat/usb.h
#include linux/regulator/consumer.h
#include linux/pm_runtime.h
+#include linux/gpio.h
/* EHCI Register Set */
#define EHCI_INSNREG04 (0xA0)
@@ -191,6 +192,19 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
}
}
+ if (pdata-phy_reset) {
+ if (gpio_is_valid(pdata-reset_gpio_port[0]))
+ gpio_request_one(pdata-reset_gpio_port[0],
+
