ulpi_check_integrity returning error

ulpi_check_integrity returning error

[Fabio Estevam]

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

ulpi_check_integrity returning error

[Arnaud Patard (Rtp)]

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

ulpi_check_integrity returning error

[Fabio Estevam]

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

ulpi_check_integrity returning error

[Arnaud Patard (Rtp)]

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

ulpi_check_integrity returning error

[Philippe Rétornaz]

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

ulpi_check_integrity returning error

[Sascha Hauer]

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 |

ulpi_check_integrity returning error

[Fabio Estevam]

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

ulpi_check_integrity returning error

[Fabio Estevam]

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