linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: valentin.longchamp@epfl.ch (Valentin Longchamp)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/1] fix occasional ULPI timeouts with ehci-mxc
Date: Wed, 02 Dec 2009 18:05:12 +0100	[thread overview]
Message-ID: <4B169E48.2000804@epfl.ch> (raw)
In-Reply-To: <20091202164930.GG14091@buzzloop.caiaq.de>

Daniel Mack wrote:
> On Wed, Dec 02, 2009 at 05:13:01PM +0100, Valentin Longchamp wrote:
>> On various mxc boards, the intial ULPI reads resulted in a timeout
>> which prevented the transceiver to be identified and thus the ehci
>> device to be probed.
>>
>> Initializing the hardware lines connected to the transceiver (through
>> pdata->init call) before actually enabling clocks and configuring
>> registers in the devices fixes this problem.
> 
> Hmm, glad to hear it fixed your problem :) However, there is no real
> ULPI communication done on the viewports before the board specific
> init function is called, and the timeouts that are reported come from
> the transceiver probing which is called at a later point.

Yeah I know, there is no reason why it would help, that's why it seemed 
strange to me too. I tried to have to the same sequence as I have with 
the ISP1504 coupled with the fsl_usb2_udc where I NEVER have a problem 
with the exact same driver and it did the trick (at least for me).

Maybe there is a bad reset or something like this earlier, that causes 
the initializations on the viewport to put the transceiver in a state 
where it cannot answer the probing.
> 
> Even with that patch applied, one board I have here fails to initialize
> the OTG port.

I have not tested it on the OTG port, only on the Host 2 (that's the 
only one I use as host on our hardware).

> 
>> Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
> 
> As it fixes a real world problem and doesn't seem to be harmful to
> anyone else:
> 
> Acked-by: Daniel Mack <daniel@caiaq.de>
> 
>>  drivers/usb/host/ehci-mxc.c |   18 +++++++++---------
>>  1 files changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
>> index 35c56f4..689b683 100644
>> --- a/drivers/usb/host/ehci-mxc.c
>> +++ b/drivers/usb/host/ehci-mxc.c
> 
> [...]
> 
>> @@ -192,15 +201,6 @@ static int ehci_mxc_drv_probe(struct platform_device *pdev)
>>  	if (ret < 0)
>>  		goto err_init;
>>  
>> -	/* call platform specific init function */
>> -	if (pdata->init) {
>> -		ret = pdata->init(pdev);
>> -		if (ret) {
>> -			dev_err(dev, "platform init failed\n");
>> -			goto err_init;
>> -		}
>> -	}
>> -
>>  	/* most platforms need some time to settle changed IO settings */
>>  	mdelay(10);
> 
> You should probably also move the mdelay() and the comment then, right?
> And as you're on it, the delay make more sense inside the
> 'if (pdata->init)' block ...

Ok, will do that

> 
> Thanks,
> Daniel
> 

Thanks for the comments and the ack, new version coming soon.

Val

-- 
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp at epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne

  reply	other threads:[~2009-12-02 17:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-02 16:13 [PATCH 1/1] fix occasional ULPI timeouts with ehci-mxc Valentin Longchamp
2009-12-02 16:49 ` Daniel Mack
2009-12-02 17:05   ` Valentin Longchamp [this message]
2009-12-03 10:35     ` Valentin Longchamp
2009-12-03 10:55       ` Daniel Mack
2009-12-02 17:36   ` Eric Bénard
2009-12-02 18:58 ` Alan Carvalho de Assis
2009-12-02 19:35   ` Andy Green
2009-12-02 20:25     ` Alan Carvalho de Assis
2009-12-02 21:13       ` Andy Green
2009-12-03  8:03         ` Valentin Longchamp
2009-12-03 14:45         ` Alan Carvalho de Assis
2009-12-03 14:53           ` Andy Green
2009-12-03 16:21             ` Alan Carvalho de Assis
2009-12-03 16:29               ` Daniel Mack
2009-12-03 16:37                 ` Alan Carvalho de Assis
2009-12-03 19:36               ` Robert Schwebel
2009-12-04  7:45                 ` javier Martin

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=4B169E48.2000804@epfl.ch \
    --to=valentin.longchamp@epfl.ch \
    --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).