* ulpi_check_integrity returning error [not found] ` <4D076E49.3020805@compulab.co.il> @ 2010-12-14 14:47 ` Fabio Estevam 2010-12-14 15:03 ` Arnaud Patard (Rtp) 2010-12-14 17:44 ` Philippe Rétornaz 0 siblings, 2 replies; 8+ messages in thread From: Fabio Estevam @ 2010-12-14 14:47 UTC (permalink / raw) To: linux-arm-kernel Hi Igor, [Adding linux-arm-kernel] On Tue, Dec 14, 2010 at 11:16 AM, Igor Grinberg <grinberg@compulab.co.il> wrote: > Hi Fabio, > > On 12/14/10 00:14, Fabio Estevam wrote: >> Hi, >> >> I am working on adding USB OTG host support for the mx31_3ds board >> (OTG PHY is a ISP1504). > > ISP1504 seems like ULPI compliant transceiver. > >> USB OTG in device mode works fine and I can only get OTG host mode to >> work if I force a 'return 0' into the ulpi_check_integrity function. I >> was wondering if anyone has any suggestions as to where to >> inspect/debug the fact that the read/write to the OTG PHY scratch >> register does not match. > > Both ULPI specifications (1.0 and 1.1) define the Scratch register as: > "an empty register byte for testing purposes. Software can read, write, > set and clear this register; and the functionality of the PHY will not be affected." > Therefore it should be implemented in the ISP1504 as such and according to > NXP's ISP1504 datasheet it should be there... > > What about the ID? Do you get the vendor/product ID value as expected? No, I am getting only zeros when reading vendor/product ID: ULPI transceiver vendor/product ID 0x0000/0x0000 Even though the ULPI integrity check fails, if I force a 'return 0' in this function, then I am able to mount a USB stick and it is functional. There are other i.MX boards that support OTG in host mode via ULPI, such as pcm037, pca100, imx27_visstrim . I am curious to know if any of this boards can work in host mode OTG with current mainline kernel. Thanks, Fabio Estevam ^ permalink raw reply [flat|nested] 8+ messages in thread
* ulpi_check_integrity returning error 2010-12-14 14:47 ` ulpi_check_integrity returning error Fabio Estevam @ 2010-12-14 15:03 ` Arnaud Patard (Rtp) 2010-12-14 16:16 ` Fabio Estevam 2010-12-14 17:44 ` Philippe Rétornaz 1 sibling, 1 reply; 8+ messages in thread From: Arnaud Patard (Rtp) @ 2010-12-14 15:03 UTC (permalink / raw) To: linux-arm-kernel Fabio Estevam <festevam@gmail.com> writes: Hi, > Hi Igor, > > [Adding linux-arm-kernel] > > On Tue, Dec 14, 2010 at 11:16 AM, Igor Grinberg <grinberg@compulab.co.il> wrote: >> Hi Fabio, >> >> On 12/14/10 00:14, Fabio Estevam wrote: >>> Hi, >>> >>> I am working on adding USB OTG host support for the mx31_3ds board >>> (OTG PHY is a ISP1504). >> >> ISP1504 seems like ULPI compliant transceiver. >> >>> USB OTG in device mode works fine and I can only get OTG host mode to >>> work if I force a 'return 0' into the ulpi_check_integrity function. I >>> was wondering if anyone has any suggestions as to where to >>> inspect/debug the fact that the read/write to the OTG PHY scratch >>> register does not match. >> >> Both ULPI specifications (1.0 and 1.1) define the Scratch register as: >> "an empty register byte for testing purposes. Software can read, write, >> set and clear this register; and the functionality of the PHY will not be affected." >> Therefore it should be implemented in the ISP1504 as such and according to >> NXP's ISP1504 datasheet it should be there... >> >> What about the ID? Do you get the vendor/product ID value as expected? > > No, I am getting only zeros when reading vendor/product ID: > > ULPI transceiver vendor/product ID 0x0000/0x0000 > > Even though the ULPI integrity check fails, if I force a 'return 0' in > this function, then I am able to mount a USB stick and it is > functional. > > There are other i.MX boards that support OTG in host mode via ULPI, > such as pcm037, pca100, imx27_visstrim . > > I am curious to know if any of this boards can work in host mode OTG > with current mainline kernel. I guess you need to configure portsc register into ulpi mode in the .init function of the mxc_usbh_platform_data otherwise, you won't be able to reach the ulpi. Thanks, Arnaud ^ permalink raw reply [flat|nested] 8+ messages in thread
* ulpi_check_integrity returning error 2010-12-14 15:03 ` Arnaud Patard (Rtp) @ 2010-12-14 16:16 ` Fabio Estevam 2010-12-14 16:26 ` Arnaud Patard (Rtp) 0 siblings, 1 reply; 8+ messages in thread From: Fabio Estevam @ 2010-12-14 16:16 UTC (permalink / raw) To: linux-arm-kernel On Tue, Dec 14, 2010 at 1:03 PM, Arnaud Patard <arnaud.patard@rtp-net.org> wrote: ... >> I am curious to know if any of this boards can work in host mode OTG >> with current mainline kernel. > > I guess you need to configure portsc register into ulpi mode in the > .init function of the mxc_usbh_platform_data otherwise, you won't be > able to reach the ulpi. Yes, I am configuring the portsc register into ULPI mode: .portsc = MXC_EHCI_MODE_ULPI, Code does reach ulpi read/write functions in arch/arm/plat-mxc/ulpi.c, but always return 0 in the reads. Regards, Fabio Estevam ^ permalink raw reply [flat|nested] 8+ messages in thread
* ulpi_check_integrity returning error 2010-12-14 16:16 ` Fabio Estevam @ 2010-12-14 16:26 ` Arnaud Patard (Rtp) 2010-12-14 22:17 ` Fabio Estevam 0 siblings, 1 reply; 8+ messages in thread From: Arnaud Patard (Rtp) @ 2010-12-14 16:26 UTC (permalink / raw) To: linux-arm-kernel Fabio Estevam <festevam@gmail.com> writes: > On Tue, Dec 14, 2010 at 1:03 PM, Arnaud Patard > <arnaud.patard@rtp-net.org> wrote: > ... >>> I am curious to know if any of this boards can work in host mode OTG >>> with current mainline kernel. >> >> I guess you need to configure portsc register into ulpi mode in the >> .init function of the mxc_usbh_platform_data otherwise, you won't be >> able to reach the ulpi. > > Yes, I am configuring the portsc register into ULPI mode: > > .portsc = MXC_EHCI_MODE_ULPI, > > Code does reach ulpi read/write functions in arch/arm/plat-mxc/ulpi.c, > but always return 0 in the reads. Please, read again what I said. I'm not talking of .portsc but of .init. To reach the ulpi, the portsc register should be set to ulpi mode _before_ calling otg_init() in ehci_mxc_drv_probe() but the code is using .portsc/setting portsc in ehci_mxc_setup() which is afaik _after_ ehci_mxc_drv_probe(). Arnaud ^ permalink raw reply [flat|nested] 8+ messages in thread
* ulpi_check_integrity returning error 2010-12-14 16:26 ` Arnaud Patard (Rtp) @ 2010-12-14 22:17 ` Fabio Estevam 2010-12-15 1:32 ` Fabio Estevam 0 siblings, 1 reply; 8+ messages in thread From: Fabio Estevam @ 2010-12-14 22:17 UTC (permalink / raw) To: linux-arm-kernel Hi Arnaud, On Tue, Dec 14, 2010 at 2:26 PM, Arnaud Patard <arnaud.patard@rtp-net.org> wrote: ... > > Please, read again what I said. I'm not talking of .portsc but of > .init. To reach the ulpi, the portsc register should be set to ulpi mode > _before_ calling otg_init() in ehci_mxc_drv_probe() but the code is using > .portsc/setting portsc in ehci_mxc_setup() which is afaik _after_ > ehci_mxc_drv_probe(). Ok, I understand what you mean now and I confirmed what you said: current code is setting the portsc register after writing to the OTG viewport. The MX31 is by default configured for a USB serial phy, so like you stated we need first to setup portsc to work in ULPI mode and after that we can read/write the OTG viewport. Thanks, Fabio Estevam ^ permalink raw reply [flat|nested] 8+ messages in thread
* ulpi_check_integrity returning error 2010-12-14 22:17 ` Fabio Estevam @ 2010-12-15 1:32 ` Fabio Estevam 0 siblings, 0 replies; 8+ messages in thread From: Fabio Estevam @ 2010-12-15 1:32 UTC (permalink / raw) To: linux-arm-kernel Arnaud, On Tue, Dec 14, 2010 at 8:17 PM, Fabio Estevam <festevam@gmail.com> wrote: > Hi Arnaud, > > On Tue, Dec 14, 2010 at 2:26 PM, Arnaud Patard > <arnaud.patard@rtp-net.org> wrote: > ... >> >> Please, read again what I said. I'm not talking of .portsc but of >> .init. To reach the ulpi, the portsc register should be set to ulpi mode >> _before_ calling otg_init() in ehci_mxc_drv_probe() but the code is using >> .portsc/setting portsc in ehci_mxc_setup() which is afaik _after_ >> ehci_mxc_drv_probe(). > > Ok, I understand what you mean now and I confirmed what you said: > current code is setting the portsc register after writing to the OTG > viewport. > > The MX31 is by default configured for a USB serial phy, so like you > stated we need first to setup portsc to work in ULPI mode and after > that we can read/write the OTG viewport. I implemented your suggestion and it worked fine on my board. Will submit a patch shortly, so that others can comment and test it. Thanks, Fabio Estevam ^ permalink raw reply [flat|nested] 8+ messages in thread
* ulpi_check_integrity returning error 2010-12-14 14:47 ` ulpi_check_integrity returning error Fabio Estevam 2010-12-14 15:03 ` Arnaud Patard (Rtp) @ 2010-12-14 17:44 ` Philippe Rétornaz 2010-12-14 20:47 ` Sascha Hauer 1 sibling, 1 reply; 8+ messages in thread From: Philippe Rétornaz @ 2010-12-14 17:44 UTC (permalink / raw) To: linux-arm-kernel Le mardi, 14 d?cembre 2010 15.47:59, Fabio Estevam a ?crit : > Hi Igor, > > [Adding linux-arm-kernel] > > On Tue, Dec 14, 2010 at 11:16 AM, Igor Grinberg <grinberg@compulab.co.il> wrote: > > Hi Fabio, > > > > On 12/14/10 00:14, Fabio Estevam wrote: > >> Hi, > >> > >> I am working on adding USB OTG host support for the mx31_3ds board > >> (OTG PHY is a ISP1504). > > > > ISP1504 seems like ULPI compliant transceiver. > > > >> USB OTG in device mode works fine and I can only get OTG host mode to > >> work if I force a 'return 0' into the ulpi_check_integrity function. I > >> was wondering if anyone has any suggestions as to where to > >> inspect/debug the fact that the read/write to the OTG PHY scratch > >> register does not match. > > > > Both ULPI specifications (1.0 and 1.1) define the Scratch register as: > > "an empty register byte for testing purposes. Software can read, write, > > set and clear this register; and the functionality of the PHY will not be > > affected." Therefore it should be implemented in the ISP1504 as such and > > according to NXP's ISP1504 datasheet it should be there... > > > > What about the ID? Do you get the vendor/product ID value as expected? > > No, I am getting only zeros when reading vendor/product ID: > > ULPI transceiver vendor/product ID 0x0000/0x0000 > > Even though the ULPI integrity check fails, if I force a 'return 0' in > this function, then I am able to mount a USB stick and it is > functional. > > There are other i.MX boards that support OTG in host mode via ULPI, > such as pcm037, pca100, imx27_visstrim . > > I am curious to know if any of this boards can work in host mode OTG > with current mainline kernel. mx31moboard_smartbot in "eyebot" mode, works. We also had some problem with the ULPI viewport not working. If you ignore the transceiver error it works. But you cannot talk directly to the transceiver, which is a problem if you want to switch on the external 5V using the isp1504. This really seems to be an imx31 hardware bug, because if you change a bit the timing of io port setup and reset of the USB state machine it works. If you are able to find an explanation to this bug (other than hardware) I'm really interested. Regards, Philippe ^ permalink raw reply [flat|nested] 8+ messages in thread
* ulpi_check_integrity returning error 2010-12-14 17:44 ` Philippe Rétornaz @ 2010-12-14 20:47 ` Sascha Hauer 0 siblings, 0 replies; 8+ messages in thread From: Sascha Hauer @ 2010-12-14 20:47 UTC (permalink / raw) To: linux-arm-kernel On Tue, Dec 14, 2010 at 06:44:37PM +0100, Philippe R?tornaz wrote: > Le mardi, 14 d?cembre 2010 15.47:59, Fabio Estevam a ?crit : > > Hi Igor, > > > > [Adding linux-arm-kernel] > > > > On Tue, Dec 14, 2010 at 11:16 AM, Igor Grinberg <grinberg@compulab.co.il> > wrote: > > > Hi Fabio, > > > > > > On 12/14/10 00:14, Fabio Estevam wrote: > > >> Hi, > > >> > > >> I am working on adding USB OTG host support for the mx31_3ds board > > >> (OTG PHY is a ISP1504). > > > > > > ISP1504 seems like ULPI compliant transceiver. > > > > > >> USB OTG in device mode works fine and I can only get OTG host mode to > > >> work if I force a 'return 0' into the ulpi_check_integrity function. I > > >> was wondering if anyone has any suggestions as to where to > > >> inspect/debug the fact that the read/write to the OTG PHY scratch > > >> register does not match. > > > > > > Both ULPI specifications (1.0 and 1.1) define the Scratch register as: > > > "an empty register byte for testing purposes. Software can read, write, > > > set and clear this register; and the functionality of the PHY will not be > > > affected." Therefore it should be implemented in the ISP1504 as such and > > > according to NXP's ISP1504 datasheet it should be there... > > > > > > What about the ID? Do you get the vendor/product ID value as expected? > > > > No, I am getting only zeros when reading vendor/product ID: > > > > ULPI transceiver vendor/product ID 0x0000/0x0000 > > > > Even though the ULPI integrity check fails, if I force a 'return 0' in > > this function, then I am able to mount a USB stick and it is > > functional. > > > > There are other i.MX boards that support OTG in host mode via ULPI, > > such as pcm037, pca100, imx27_visstrim . > > > > I am curious to know if any of this boards can work in host mode OTG > > with current mainline kernel. > > mx31moboard_smartbot in "eyebot" mode, works. We also had some problem with > the ULPI viewport not working. If you ignore the transceiver error it works. > But you cannot talk directly to the transceiver, which is a problem if you > want to switch on the external 5V using the isp1504. > > This really seems to be an imx31 hardware bug, because if you change a bit the > timing of io port setup and reset of the USB state machine it works. > > If you are able to find an explanation to this bug (other than hardware) I'm > really interested. We too had problems on different boards with the ULPI viewport (i.MX31 but also i.MX27). This depends on the order the iomuxer is set up, then add a delay here and not too much there and then it works. The initialization order in the mxc ehci driver was changed sometimes to work around these bugs, but it doesn't make me wonder that there are boards where it doesn't work. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-12-15 1:32 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <AANLkTinxLr10X-EBGQHdhC5JyxbJOqcUz_+UMOCo+OFA@mail.gmail.com>
[not found] ` <4D076E49.3020805@compulab.co.il>
2010-12-14 14:47 ` ulpi_check_integrity returning error Fabio Estevam
2010-12-14 15:03 ` Arnaud Patard (Rtp)
2010-12-14 16:16 ` Fabio Estevam
2010-12-14 16:26 ` Arnaud Patard (Rtp)
2010-12-14 22:17 ` Fabio Estevam
2010-12-15 1:32 ` Fabio Estevam
2010-12-14 17:44 ` Philippe Rétornaz
2010-12-14 20:47 ` Sascha Hauer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).