[U-Boot] [PATCH] ehci-hcd: Allow cleanups to happen on an EHCI timeout.

[U-Boot] [PATCH] ehci-hcd: Allow cleanups to happen on an EHCI timeout.

[Joel A Fernandes]

With this, the EHCI seems to "recover" from a timeout. This is particularly
observable if you were to ping the wrong IP Address and then ping the correct
one or if there was a temporary failure during tftp sessions.

All it takes is one timeout to disable it. If you have a noisy network (lot
of traffic), even if the traffic is not for the board, the timeouts don't occur.

Signed-off-by: Joel A Fernandes <agnel.joel@gmail.com>
---
Robert, Could you see if this patch solves the issue you're seeing without
increasing the timeout?
Simon, Could this be a fix for a similar issue you were seeing with asix?

 drivers/usb/host/ehci-hcd.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 243bb39..9bfcbae 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -464,7 +464,6 @@ ehci_submit_async(struct usb_device *dev, unsigned long pipe, void *buffer,
 	/* Check that the TD processing happened */
 	if (token & 0x80) {
 		printf("EHCI timed out on TD - token=%#x\n", token);
-		goto fail;
 	}
 
 	/* Disable async schedule. */
-- 
1.7.1

[U-Boot] [PATCH] ehci-hcd: Allow cleanups to happen on an EHCI timeout.

[Robert Berger]

Hi Joel,

On 06/25/2011 10:28 PM, Joel A Fernandes wrote:
> ---
> Robert, Could you see if this patch solves the issue you're seeing without
> increasing the timeout?

The tftp session retrieves the uImage with your patch and a timeout of 5000:

OMAP3 beagleboard.org # tftp 0x82000000 beagle-xm-rev-c/uImage
Waiting for Ethernet connection... done.
Using sms0 device
TFTP from server 192.168.5.5; our IP address is 192.168.5.3
Filename 'beagle-xm-rev-c/uImage'.
Load address: 0x82000000
Loading: #################################################################
	 ############################################################EHCI timed
out on TD - token=0x88008d80
T EHCI timed out on TD - token=0x88008d80
T EHCI timed out on TD - token=0x88008d80
T #####
	 ###################################EHCI timed out on TD - token=0x88008d80
T EHCI timed out on TD - token=0x88008d80
T EHCI timed out on TD - token=0x88008d80
T #EHCI timed out on TD - token=0x88008d80
T ##############
done
Bytes transferred = 2632196 (282a04 hex)
OMAP3 beagleboard.org #

Regards,

Robert...fortune says today:There is no TRUTH.  There is no REALITY.
There is no CONSISTENCY. There are no ABSOLUTE STATEMENTS   I'm very
probably wrong.

My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1

[U-Boot] [PATCH] ehci-hcd: Allow cleanups to happen on an EHCI timeout.

[2bluesc at gmail.com]

Koen grabbed some patches I added that seemed to "fix" the tftpboot and ping 
problem for me:

https://github.com/koenkooi/u-boot
or my fork @ https://github.com/kylemanna/u-boot

I'd be interested to hear if adding the delay at the end of the smsc95xx 
init helped your problem at all.

- Kyle

[U-Boot] [PATCH] ehci-hcd: Allow cleanups to happen on an EHCI timeout.

[Simon Glass]

Hi Joel,

On Sat, Jun 25, 2011 at 12:28 PM, Joel A Fernandes <agnel.joel@gmail.com> wrote:
> With this, the EHCI seems to "recover" from a timeout. This is particularly
> observable if you were to ping the wrong IP Address and then ping the correct
> one or if there was a temporary failure during tftp sessions.
>
> All it takes is one timeout to disable it. If you have a noisy network (lot
> of traffic), even if the traffic is not for the board, the timeouts don't occur.
>
> Signed-off-by: Joel A Fernandes <agnel.joel@gmail.com>
> ---
> Robert, Could you see if this patch solves the issue you're seeing without
> increasing the timeout?
> Simon, Could this be a fix for a similar issue you were seeing with asix?

Yes this is better (ASIX can recover from a timeout), but I am
concerned that it carries on without reporting an error. Is that
right?

Should we disable async schedule and then return an error?

With respect to using a bulk USB stick (some of which take 3s or more
to respond to a submit) this doesn't make any difference for me. It
seems to take a long time to respond the first time, so the 5s timeout
seems prudent.

Since this sorts out the network side we can probably skip that patch.

Regards,
Simon

>
> ?drivers/usb/host/ehci-hcd.c | ? ?1 -
> ?1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> index 243bb39..9bfcbae 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -464,7 +464,6 @@ ehci_submit_async(struct usb_device *dev, unsigned long pipe, void *buffer,
> ? ? ? ?/* Check that the TD processing happened */
> ? ? ? ?if (token & 0x80) {
> ? ? ? ? ? ? ? ?printf("EHCI timed out on TD - token=%#x\n", token);
> - ? ? ? ? ? ? ? goto fail;
> ? ? ? ?}
>
> ? ? ? ?/* Disable async schedule. */
> --
> 1.7.1
>
>
>