linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: arnaud.patard@rtp-net.org (Arnaud Patard (Rtp))
To: linux-arm-kernel@lists.infradead.org
Subject: ulpi_check_integrity returning error
Date: Tue, 14 Dec 2010 16:03:46 +0100	[thread overview]
Message-ID: <87d3p4e6r1.fsf@lechat.rtp-net.org> (raw)
In-Reply-To: <AANLkTintiOa5mhcF_viNCzC5q1EEHjgTLHhYsJc5Un-5@mail.gmail.com> (Fabio Estevam's message of "Tue, 14 Dec 2010 12:47:59 -0200")

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

  reply	other threads:[~2010-12-14 15:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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) [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d3p4e6r1.fsf@lechat.rtp-net.org \
    --to=arnaud.patard@rtp-net.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).