Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
Hi everyone, Sorry for the late test but I had other tasks... I just had some time to look at it and test it. Le 30/09/2013 09:47, Mylene Josserand a écrit : Le 29/09/2013 19:08, Christoph Fritz a écrit : On Sun, 2013-09-29 at 12:19 -0300, Fabio Estevam wrote: On Sun, Sep 29, 2013 at 11:32 AM, Christoph Fritz chf.fr...@googlemail.com wrote: Le 26/09/2013 17:59, Christoph Fritz a écrit : Their software fix: As first attemp at fixing this issue, one may try to switch LINK to ULPI mode before configuring MUX and pads for USB operation. Fear is that this could cause unexpected transfer from PHY to LINK, somehow preventing proper initialization I'll try that here with the smsc3340-phy. What a mess, it is also important in what order the muxing of USB-Pins is done beside the fact that some USBOTG pins had a GPIO_OUT configured wrongly. Don't ask how I hit this, but with that and the info from above finally both smsc3340 phys on OTG and USBH2 get detected: pure Can you show a patch or code so that others could fix this problem as well? Sure, attached to this mail are 4 of my work-in-progress patches, two for barebox and two for the kernel. Consider them RFC. The ULPI-mode switching before muxing is already part of barebox. Thanks -- Christoph Thank you very much, Christoph ! I really like having good news like this to start the working week :D I will try to test it this week ! I hope it will work for me too :) Unfortunately, I don't know if I missed any configurations but the SMSC 3340 is still not working in my case.. :( I test it with a 2.6.32 kernel. The phy seems to be detected (same thing before the patches) but when I plug an USB-key, no reaction in the kernel. ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver mxc-ehci mxc-ehci.2: initializing i.MX USB Controller navocap_cedalion_h2_gpioinit done mxc-ehci mxc-ehci.2: Freescale On-Chip EHCI Host Controller mxc-ehci mxc-ehci.2: new USB bus registered, assigned bus number 1 mxc-ehci mxc-ehci.2: irq 55, io mem 0x10024400 mxc-ehci mxc-ehci.2: USB 2.0 started, EHCI 1.00 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected mxc-ehci mxc-ehci.0: initializing i.MX USB Controller navocap_cedalion_otg_gpioinit done mxc-ehci mxc-ehci.0: Freescale On-Chip EHCI Host Controller mxc-ehci mxc-ehci.0: new USB bus registered, assigned bus number 2 mxc-ehci mxc-ehci.0: irq 56, io mem 0x10024000 mxc-ehci mxc-ehci.0: USB 2.0 started, EHCI 1.00 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 1 port detected I test it with a 8.2 kernel too and I have the same previous error timeout polling : ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.0: unable to init transceiver, probably missing mxc-ehci mxc-ehci.2: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.2: unable to init transceiver, probably missing Initializing USB Mass Storage driver... Christoph, you are using a 3.4 kernel, is not it ? I will continue to search but I have no experience on USB (and I am learning with it how works BSP too) so any help would be very appreciated. If I make any progress, I will post it on this mail-list, of course ! Best regards, -- Mylène JOSSERAND
Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
Le 15/10/2013 11:48, Mylene Josserand a écrit : Unfortunately, I don't know if I missed any configurations but the SMSC 3340 is still not working in my case.. :( I test it with a 2.6.32 kernel. The phy seems to be detected (same thing before the patches) but when I plug an USB-key, no reaction in the kernel. ah ! I was wrong, in fact, the OTG port did not react but the H2 reacts with an USB key : usb 1-1: new low speed USB device using mxc-ehci and address 2 usb 1-1: device descriptor read/64, error -71 usb 1-1: device descriptor read/64, error -71 usb 1-1: new low speed USB device using mxc-ehci and address 3 usb 1-1: device descriptor read/64, error -71 usb 1-1: device descriptor read/64, error -71 usb 1-1: new low speed USB device using mxc-ehci and address 4 usb 1-1: device not accepting address 4, error -71 usb 1-1: new low speed USB device using mxc-ehci and address 5 usb 1-1: device not accepting address 5, error -71 hub 1-0:1.0: unable to enumerate USB device on port 1 What is the code error -71 ? In this thread (https://bbs.archlinux.org/viewtopic.php?id=149708), seems to be a EPROTO error. Is it right ? What is it due to ? -- Mylène JOSSERAND
Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
Hi, Le 29/09/2013 19:08, Christoph Fritz a écrit : On Sun, 2013-09-29 at 12:19 -0300, Fabio Estevam wrote: On Sun, Sep 29, 2013 at 11:32 AM, Christoph Fritz chf.fr...@googlemail.com wrote: Le 26/09/2013 17:59, Christoph Fritz a écrit : Their software fix: As first attemp at fixing this issue, one may try to switch LINK to ULPI mode before configuring MUX and pads for USB operation. Fear is that this could cause unexpected transfer from PHY to LINK, somehow preventing proper initialization I'll try that here with the smsc3340-phy. What a mess, it is also important in what order the muxing of USB-Pins is done beside the fact that some USBOTG pins had a GPIO_OUT configured wrongly. Don't ask how I hit this, but with that and the info from above finally both smsc3340 phys on OTG and USBH2 get detected: pure Can you show a patch or code so that others could fix this problem as well? Sure, attached to this mail are 4 of my work-in-progress patches, two for barebox and two for the kernel. Consider them RFC. The ULPI-mode switching before muxing is already part of barebox. Thanks -- Christoph Thank you very much, Christoph ! I really like having good news like this to start the working week :D I will try to test it this week ! I hope it will work for me too :) Best regards, -- Mylène JOSSERAND Navocap
Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
Le 26/09/2013 17:59, Christoph Fritz a écrit : Their software fix: As first attemp at fixing this issue, one may try to switch LINK to ULPI mode before configuring MUX and pads for USB operation. Fear is that this could cause unexpected transfer from PHY to LINK, somehow preventing proper initialization I'll try that here with the smsc3340-phy. What a mess, it is also important in what order the muxing of USB-Pins is done beside the fact that some USBOTG pins had a GPIO_OUT configured wrongly. Don't ask how I hit this, but with that and the info from above finally both smsc3340 phys on OTG and USBH2 get detected: pure *voodooo*! @Sascha in arch/arm/mach-imx/include/mach/iomux-mx27.h why were the USBOTG pins configured with GPIO_OUT all along? :-) -- Christoph -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
On Sun, Sep 29, 2013 at 11:32 AM, Christoph Fritz chf.fr...@googlemail.com wrote: Le 26/09/2013 17:59, Christoph Fritz a écrit : Their software fix: As first attemp at fixing this issue, one may try to switch LINK to ULPI mode before configuring MUX and pads for USB operation. Fear is that this could cause unexpected transfer from PHY to LINK, somehow preventing proper initialization I'll try that here with the smsc3340-phy. What a mess, it is also important in what order the muxing of USB-Pins is done beside the fact that some USBOTG pins had a GPIO_OUT configured wrongly. Don't ask how I hit this, but with that and the info from above finally both smsc3340 phys on OTG and USBH2 get detected: pure Can you show a patch or code so that others could fix this problem as well? Regards, Fabio Estevam -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
On Sun, 2013-09-29 at 12:19 -0300, Fabio Estevam wrote:
On Sun, Sep 29, 2013 at 11:32 AM, Christoph Fritz
chf.fr...@googlemail.com wrote:
Le 26/09/2013 17:59, Christoph Fritz a écrit :
Their software fix:
As first attemp at fixing this issue, one may try to switch LINK to
ULPI mode before configuring MUX and pads for USB operation. Fear is
that this could cause unexpected transfer from PHY to LINK, somehow
preventing proper initialization
I'll try that here with the smsc3340-phy.
What a mess, it is also important in what order the muxing of USB-Pins
is done beside the fact that some USBOTG pins had a GPIO_OUT configured
wrongly. Don't ask how I hit this, but with that and the info from above
finally both smsc3340 phys on OTG and USBH2 get detected: pure
Can you show a patch or code so that others could fix this problem as well?
Sure, attached to this mail are 4 of my work-in-progress patches, two
for barebox and two for the kernel. Consider them RFC. The ULPI-mode
switching before muxing is already part of barebox.
Thanks
-- Christoph
From a5f16b4cee15ea239d90bc4c18db3d9628afecec Mon Sep 17 00:00:00 2001
From: Christoph Fritz chf.fr...@googlemail.com
Date: Sat, 28 Sep 2013 12:41:30 +0200
Subject: [PATCH 2/2] i.MX27: fix USBOTG muxing
Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
---
arch/arm/mach-imx/include/mach/iomux-mx27.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-imx/include/mach/iomux-mx27.h b/arch/arm/mach-imx/include/mach/iomux-mx27.h
index 23e448b..6ff8651 100644
--- a/arch/arm/mach-imx/include/mach/iomux-mx27.h
+++ b/arch/arm/mach-imx/include/mach/iomux-mx27.h
@@ -38,13 +38,13 @@
#define PB25_PF_USBH1_RCV (GPIO_PORTB | GPIO_PF | 25)
#define PC5_PF_I2C2_SDA (GPIO_PORTC | GPIO_PF | GPIO_IN | 5)
#define PC6_PF_I2C2_SCL (GPIO_PORTC | GPIO_PF | GPIO_IN | 6)
-#define PC7_PF_USBOTG_DATA5 (GPIO_PORTC | GPIO_PF | GPIO_OUT | 7)
-#define PC8_PF_USBOTG_DATA6 (GPIO_PORTC | GPIO_PF | GPIO_OUT | 8)
-#define PC9_PF_USBOTG_DATA0 (GPIO_PORTC | GPIO_PF | GPIO_OUT | 9)
-#define PC10_PF_USBOTG_DATA2 (GPIO_PORTC | GPIO_PF | GPIO_OUT | 10)
-#define PC11_PF_USBOTG_DATA1 (GPIO_PORTC | GPIO_PF | GPIO_OUT | 11)
-#define PC12_PF_USBOTG_DATA4 (GPIO_PORTC | GPIO_PF | GPIO_OUT | 12)
-#define PC13_PF_USBOTG_DATA3 (GPIO_PORTC | GPIO_PF | GPIO_OUT | 13)
+#define PC7_PF_USBOTG_DATA5 (GPIO_PORTC | GPIO_PF | 7)
+#define PC8_PF_USBOTG_DATA6 (GPIO_PORTC | GPIO_PF | 8)
+#define PC9_PF_USBOTG_DATA0 (GPIO_PORTC | GPIO_PF | 9)
+#define PC10_PF_USBOTG_DATA2 (GPIO_PORTC | GPIO_PF | 10)
+#define PC11_PF_USBOTG_DATA1 (GPIO_PORTC | GPIO_PF | 11)
+#define PC12_PF_USBOTG_DATA4 (GPIO_PORTC | GPIO_PF | 12)
+#define PC13_PF_USBOTG_DATA3 (GPIO_PORTC | GPIO_PF | 13)
#define PC16_PF_SSI4_FS (GPIO_PORTC | GPIO_PF | GPIO_IN | 16)
#define PC17_PF_SSI4_RXD (GPIO_PORTC | GPIO_PF | GPIO_IN | 17)
#define PC18_PF_SSI4_TXD (GPIO_PORTC | GPIO_PF | GPIO_IN | 18)
@@ -66,11 +66,11 @@
#define PD14_PF_ATA_DATA12 (GPIO_PORTD | GPIO_PF | 14)
#define PD15_PF_ATA_DATA13 (GPIO_PORTD | GPIO_PF | 15)
#define PD16_PF_ATA_DATA14 (GPIO_PORTD | GPIO_PF | 16)
-#define PE0_PF_USBOTG_NXT (GPIO_PORTE | GPIO_PF | GPIO_OUT | 0)
-#define PE1_PF_USBOTG_STP (GPIO_PORTE | GPIO_PF | GPIO_OUT | 1)
-#define PE2_PF_USBOTG_DIR (GPIO_PORTE | GPIO_PF | GPIO_OUT | 2)
-#define PE24_PF_USBOTG_CLK (GPIO_PORTE | GPIO_PF | GPIO_OUT | 24)
-#define PE25_PF_USBOTG_DATA7 (GPIO_PORTE | GPIO_PF | GPIO_OUT | 25)
+#define PE0_PF_USBOTG_NXT (GPIO_PORTE | GPIO_PF | 0)
+#define PE1_PF_USBOTG_STP (GPIO_PORTE | GPIO_PF | 1)
+#define PE2_PF_USBOTG_DIR (GPIO_PORTE | GPIO_PF | 2)
+#define PE24_PF_USBOTG_CLK (GPIO_PORTE | GPIO_PF | 24)
+#define PE25_PF_USBOTG_DATA7 (GPIO_PORTE | GPIO_PF | 25)
#define PF1_PF_NFCLE (GPIO_PORTF | GPIO_PF | 1)
#define PF3_PF_NFCE (GPIO_PORTF | GPIO_PF | 3)
#define PF7_PF_PC_POE (GPIO_PORTF | GPIO_PF | 7)
--
1.7.10.4
From d6390bcfa4435af350f3c76a369954824fec76ea Mon Sep 17 00:00:00 2001
From: Christoph Fritz chf.fr...@googlemail.com
Date: Fri, 27 Sep 2013 17:07:43 +0200
Subject: [PATCH 1/2] ARM: pca100: fix USB muxing order
The order of muxing USB-Pins seems to be important when ULPI-Mode
is configured. ULPI-Mode is and needs to be set before muxing, which
is already done for pca100.
Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
---
arch/arm/boards/phycard-i.MX27/pca100.c | 40 +--
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boards/phycard-i.MX27/pca100.c b/arch/arm/boards/phycard-i.MX27/pca100.c
index 8ea7b0d..03be662 100644
--- a/arch/arm/boards/phycard-i.MX27/pca100.c
+++ b/arch/arm/boards/phycard-i.MX27/pca100.c
@@ -201,6 +201,33 @@ static int pca100_devices_init(void)
struct device_d *nand;
unsigned int mode[] = {
+ /* USB host 2 */
+ PA2_PF_USBH2_DATA7,
+ PD21_AF_USBH2_DATA6,
+ PD26_AF_USBH2_DATA5,
+ PD19_AF_USBH2_DATA4,
+
Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
Hi everyone, Sorry for the late answer ! Le 26/09/2013 17:59, Christoph Fritz a écrit : On Wed, 2013-09-25 at 16:00 +0200, Eric Bénard wrote: Le Wed, 25 Sep 2013 12:17:40 +0200, Christoph Fritz chf.fr...@googlemail.com a écrit : On Tue, 2013-04-09 at 14:28 -0300, Fabio Estevam wrote: On Mon, Apr 8, 2013 at 9:09 PM, Fabio Estevam feste...@gmail.com wrote: I know that I have to use the driver ULPI but with my configuration, I get these errors : ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.0: unable to init transceiver, probably missing Just tested mx31pdk on a 3.8.6 kernel and I got: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller ULPI transceiver vendor/product ID 0x04cc/0x1504 Found NXP ISP1504 ULPI transceiver. ULPI integrity check: passed. mxc-ehci mxc-ehci.0: EHCI Host Controller mxc-ehci mxc-ehci.0: new USB bus registered, assigned bus number 1 mxc-ehci mxc-ehci.0: irq 53, io mem 0x43f88000 mxc-ehci mxc-ehci.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected mxc-ehci mxc-ehci.2: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.2: unable to init transceiver, probably missing Any updates on this? For me, no updates about ISP1504. But we wants to change the ISP1504 by the SMSC 3340 to have a reset pin. So we are trying to detect this USB phy with an IMX27 too ! And unfortunately, we have the same problem with the ULPI detection (and tested with different kernel versions). We are having some help with the support to try to know why it is not detected. I will let you know when I have updates but right now, we are still searching why. But we have found that some pins DATA [1 and 6] stay high even after the reset [probably a problem with the SoC configuration ?]. I will let you know if we succeed to make it work, how and why we had these problems ! I'm facing the same kind of issue with an SMSC3340 phy connected to an imx.27: After some minutes in power-off state, the first boot fails to detect the ULPI device connected to USBOTG-Pins, no matter if host- or device-mode is configured. But the strange thing is that then, after a reboot or reset the phy gets detected. You succeeded to get it detected with a reboot ? It is great but strange. are you sure some pins on the ULPI interface don't change their level between the time where you release the PHY's reset and when the ULPI access occurs ? I'm pretty sure that there are, but not intended by software I could control (bootloader+kernel). I got a pdf entitled Using ISP1504 with i.MX27 which is a Freescale-Hardware-Bug-Tech-Note from 2008. It's about the same problem we are facing here in this thread. To quote their conclusion: - i.MX27 HS OTG core is software configurable for ULPI or Serial transceiver interface - Default setup at power-up is for Serial transceiver - This has been found to cause problems with ISP1504 ULPI High- Speed USB OTG transceiver - Problems appear rarely and randomly during system power-up - Final result is that sometimes ISP1504 enters suspend mode during startup preventing proper initialization via ULPI bus Their software fix: As first attemp at fixing this issue, one may try to switch LINK to ULPI mode before configuring MUX and pads for USB operation. Fear is that this could cause unexpected transfer from PHY to LINK, somehow preventing proper initialization I'll try that here with the smsc3340-phy. Very interesting ! Please drop me a private mail if you want me to send the pdf to you. It would be great if you could send me this pdf ! :) Thanks -- Christoph Thanks, Best regards, -- Mylène JOSSERAND Navocap
Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
Hi, Le Thu, 26 Sep 2013 17:59:39 +0200, Christoph Fritz chf.fr...@googlemail.com a écrit : On Wed, 2013-09-25 at 16:00 +0200, Eric Bénard wrote: Le Wed, 25 Sep 2013 12:17:40 +0200, Christoph Fritz chf.fr...@googlemail.com a écrit : On Tue, 2013-04-09 at 14:28 -0300, Fabio Estevam wrote: On Mon, Apr 8, 2013 at 9:09 PM, Fabio Estevam feste...@gmail.com wrote: I know that I have to use the driver ULPI but with my configuration, I get these errors : ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.0: unable to init transceiver, probably missing Just tested mx31pdk on a 3.8.6 kernel and I got: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller ULPI transceiver vendor/product ID 0x04cc/0x1504 Found NXP ISP1504 ULPI transceiver. ULPI integrity check: passed. mxc-ehci mxc-ehci.0: EHCI Host Controller mxc-ehci mxc-ehci.0: new USB bus registered, assigned bus number 1 mxc-ehci mxc-ehci.0: irq 53, io mem 0x43f88000 mxc-ehci mxc-ehci.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected mxc-ehci mxc-ehci.2: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.2: unable to init transceiver, probably missing Any updates on this? I'm facing the same kind of issue with an SMSC3340 phy connected to an imx.27: After some minutes in power-off state, the first boot fails to detect the ULPI device connected to USBOTG-Pins, no matter if host- or device-mode is configured. But the strange thing is that then, after a reboot or reset the phy gets detected. are you sure some pins on the ULPI interface don't change their level between the time where you release the PHY's reset and when the ULPI access occurs ? I'm pretty sure that there are, but not intended by software I could control (bootloader+kernel). from memory we had this problem with ISP1504 a few years ago and this only real fix was to switch to an other PHY with a reset to unlock it when bad things happen. Eric -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
On Tue, 2013-04-09 at 14:28 -0300, Fabio Estevam wrote: On Mon, Apr 8, 2013 at 9:09 PM, Fabio Estevam feste...@gmail.com wrote: I know that I have to use the driver ULPI but with my configuration, I get these errors : ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.0: unable to init transceiver, probably missing Just tested mx31pdk on a 3.8.6 kernel and I got: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller ULPI transceiver vendor/product ID 0x04cc/0x1504 Found NXP ISP1504 ULPI transceiver. ULPI integrity check: passed. mxc-ehci mxc-ehci.0: EHCI Host Controller mxc-ehci mxc-ehci.0: new USB bus registered, assigned bus number 1 mxc-ehci mxc-ehci.0: irq 53, io mem 0x43f88000 mxc-ehci mxc-ehci.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected mxc-ehci mxc-ehci.2: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.2: unable to init transceiver, probably missing Any updates on this? I'm facing the same kind of issue with an SMSC3340 phy connected to an imx.27: After some minutes in power-off state, the first boot fails to detect the ULPI device connected to USBOTG-Pins, no matter if host- or device-mode is configured. But the strange thing is that then, after a reboot or reset the phy gets detected. Could this be related to the following errata? http://www.freescale.com/files/32bit/doc/errata/MCIMX27CE.pdf Number: bo58229 Module Affected: USB Title: A remote wake-up can be interpreted as a disconnect Description: In Host mode in the ULPI core, a remote wake-up can be interpreted as a disconnect. This issue involves the latency when asserting in synchronous mode. In some instances, the host will not properly latch the K state. When this occurs, the core wakes up to a J state. Eventually the host will not resume, and will show an SE0 and assume a disconnect occurred. What seems to workaround the problem is when you do a reset of the phy by a GPIO line right before USB initialization. But guess what, here is normally no reset-line connected to the smsc3340. Thanks -- Christoph -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
Hi Christoph, On Wed, Sep 25, 2013 at 7:17 AM, Christoph Fritz chf.fr...@googlemail.com wrote: On Tue, 2013-04-09 at 14:28 -0300, Fabio Estevam wrote: On Mon, Apr 8, 2013 at 9:09 PM, Fabio Estevam feste...@gmail.com wrote: I know that I have to use the driver ULPI but with my configuration, I get these errors : ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.0: unable to init transceiver, probably missing Just tested mx31pdk on a 3.8.6 kernel and I got: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller ULPI transceiver vendor/product ID 0x04cc/0x1504 Found NXP ISP1504 ULPI transceiver. ULPI integrity check: passed. mxc-ehci mxc-ehci.0: EHCI Host Controller mxc-ehci mxc-ehci.0: new USB bus registered, assigned bus number 1 mxc-ehci mxc-ehci.0: irq 53, io mem 0x43f88000 mxc-ehci mxc-ehci.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected mxc-ehci mxc-ehci.2: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.2: unable to init transceiver, probably missing Any updates on this? I'm facing the same kind of issue with an SMSC3340 phy connected to an imx.27: After some minutes in power-off state, the first boot fails to detect the ULPI device connected to USBOTG-Pins, no matter if host- or device-mode is configured. But the strange thing is that then, after a reboot or reset the phy gets detected. I haven't looked closely at this issue since then. Are you able to use the chipidea driver instead of the ehci-mxc? Regards, Fabio Estevam -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
On Wed, 2013-09-25 at 10:09 -0300, Fabio Estevam wrote: Hi Christoph, On Wed, Sep 25, 2013 at 7:17 AM, Christoph Fritz chf.fr...@googlemail.com wrote: On Tue, 2013-04-09 at 14:28 -0300, Fabio Estevam wrote: On Mon, Apr 8, 2013 at 9:09 PM, Fabio Estevam feste...@gmail.com wrote: I know that I have to use the driver ULPI but with my configuration, I get these errors : ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.0: unable to init transceiver, probably missing Just tested mx31pdk on a 3.8.6 kernel and I got: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller ULPI transceiver vendor/product ID 0x04cc/0x1504 Found NXP ISP1504 ULPI transceiver. ULPI integrity check: passed. mxc-ehci mxc-ehci.0: EHCI Host Controller mxc-ehci mxc-ehci.0: new USB bus registered, assigned bus number 1 mxc-ehci mxc-ehci.0: irq 53, io mem 0x43f88000 mxc-ehci mxc-ehci.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected mxc-ehci mxc-ehci.2: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.2: unable to init transceiver, probably missing Any updates on this? I'm facing the same kind of issue with an SMSC3340 phy connected to an imx.27: After some minutes in power-off state, the first boot fails to detect the ULPI device connected to USBOTG-Pins, no matter if host- or device-mode is configured. But the strange thing is that then, after a reboot or reset the phy gets detected. I haven't looked closely at this issue since then. Are you able to use the chipidea driver instead of the ehci-mxc? No, I'm not. Is there already glue-code for imx.27 ? Thanks -- Christoph -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
On Wed, Sep 25, 2013 at 10:25 AM, Christoph Fritz chf.fr...@googlemail.com wrote: Are you able to use the chipidea driver instead of the ehci-mxc? No, I'm not. Is there already glue-code for imx.27 ? It still needs a usbmisc_imx27_init() entry in drivers/usb/chipidea/usbmisc_imx.c Regards, Fabio Estevam -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
On Wed, 2013-09-25 at 10:34 -0300, Fabio Estevam wrote: On Wed, Sep 25, 2013 at 10:25 AM, Christoph Fritz chf.fr...@googlemail.com wrote: Are you able to use the chipidea driver instead of the ehci-mxc? No, I'm not. Is there already glue-code for imx.27 ? It still needs a usbmisc_imx27_init() entry in drivers/usb/chipidea/usbmisc_imx.c mhm.. damn, I'm stuck here with a 3.4.x without drivers/usb/chipidea/usbmisc_imx.c. But isn't ULPI detection before loading an USB driver? regards -- Christoph -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
On Wed, Sep 25, 2013 at 10:50 AM, Christoph Fritz chf.fr...@googlemail.com wrote: mhm.. damn, I'm stuck here with a 3.4.x without drivers/usb/chipidea/usbmisc_imx.c. But isn't ULPI detection before loading an USB driver? Not really, mxc-ehci driver is loaded first. Please see the log: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller ULPI transceiver vendor/product ID 0x04cc/0x1504 Found NXP ISP1504 ULPI transceiver. ULPI integrity check: passed. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
Hi Christoph, Le Wed, 25 Sep 2013 12:17:40 +0200, Christoph Fritz chf.fr...@googlemail.com a écrit : On Tue, 2013-04-09 at 14:28 -0300, Fabio Estevam wrote: On Mon, Apr 8, 2013 at 9:09 PM, Fabio Estevam feste...@gmail.com wrote: I know that I have to use the driver ULPI but with my configuration, I get these errors : ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.0: unable to init transceiver, probably missing Just tested mx31pdk on a 3.8.6 kernel and I got: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller ULPI transceiver vendor/product ID 0x04cc/0x1504 Found NXP ISP1504 ULPI transceiver. ULPI integrity check: passed. mxc-ehci mxc-ehci.0: EHCI Host Controller mxc-ehci mxc-ehci.0: new USB bus registered, assigned bus number 1 mxc-ehci mxc-ehci.0: irq 53, io mem 0x43f88000 mxc-ehci mxc-ehci.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected mxc-ehci mxc-ehci.2: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.2: unable to init transceiver, probably missing Any updates on this? I'm facing the same kind of issue with an SMSC3340 phy connected to an imx.27: After some minutes in power-off state, the first boot fails to detect the ULPI device connected to USBOTG-Pins, no matter if host- or device-mode is configured. But the strange thing is that then, after a reboot or reset the phy gets detected. are you sure some pins on the ULPI interface don't change their level between the time where you release the PHY's reset and when the ULPI access occurs ? Eric -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
On Mon, Apr 8, 2013 at 9:09 PM, Fabio Estevam feste...@gmail.com wrote: I know that I have to use the driver ULPI but with my configuration, I get these errors : ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.0: unable to init transceiver, probably missing Just tested mx31pdk on a 3.8.6 kernel and I got: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller ULPI transceiver vendor/product ID 0x04cc/0x1504 Found NXP ISP1504 ULPI transceiver. ULPI integrity check: passed. mxc-ehci mxc-ehci.0: EHCI Host Controller mxc-ehci mxc-ehci.0: new USB bus registered, assigned bus number 1 mxc-ehci mxc-ehci.0: irq 53, io mem 0x43f88000 mxc-ehci mxc-ehci.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected mxc-ehci mxc-ehci.2: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.2: unable to init transceiver, probably missing This board has one USB otg port and another USB Host2 port. The USB otg port probed correctly and it works in host mode. However the USB Host2 port failed in the same way as in mx27. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
Hi Mylene, On Mon, Apr 8, 2013 at 10:41 AM, Mylene Josserand mylene.josser...@navocap.com wrote: Hi everyone, I need some help to understand how USB is configured. I am updating an old kernel (2.6.32 !) to the version 3.8.2. I am self-taught on Linux kernel so, sometimes, I need the help of the community to understand it :) The SoC is a IMX27. For the USB side, we have a NXP ISP1504. I know that I have to use the driver ULPI but with my configuration, I get these errors : ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.0: unable to init transceiver, probably missing I can reproduce it here as well on a mx27pdk. I thought the issue could be due to the conversion to the common clock framework, but then I tested a 3.2 kernel and I got the same behavior. Adding Sascha /Eric/Javier, in case they have recently tried USB host on mx27 recently. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
