Hi, Le Thu, 26 Sep 2013 17:59:39 +0200, Christoph Fritz <chf.fritz@xxxxxxxxxxxxxx> 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.fritz@xxxxxxxxxxxxxx> 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 <festevam@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
