On Thu, Jul 28, 2011 at 12:16:00PM -0700, Prafulla Wadaskar wrote:
-----Original Message----- From: Jason [mailto:u-boot@lakedaemon.net] Sent: Thursday, July 28, 2011 7:07 AM To: Prafulla Wadaskar Cc: clint@debian.org; wd@denx.de; u-boot@lists.denx.de; Prabhanjan Sarnaik; Ashish Karkare; Siddarth Gore; bdale@gag.com Subject: Re: RFC [PATCH 3/5] usb: Some EHCI chipsets are slow to respond.
On Wed, Jul 27, 2011 at 11:23:50AM -0700, Prafulla Wadaskar wrote:
-----Original Message----- From: Jason Cooper [mailto:u-boot@lakedaemon.net] Sent: Wednesday, July 27, 2011 2:49 AM To: clint@debian.org; wd@denx.de; Prafulla Wadaskar Cc: u-boot@lists.denx.de; Prabhanjan Sarnaik; Ashish Karkare;
Siddarth
Gore; bdale@gag.com; Jason Cooper Subject: RFC [PATCH 3/5] usb: Some EHCI chipsets are slow to
respond.
This fixes 'EHCI timed out on TD...' on the dreamplug board.
Signed-off-by: Jason Cooper u-boot@lakedaemon.net
include/usb.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/usb.h b/include/usb.h index 53603a5..168e2b2 100644 --- a/include/usb.h +++ b/include/usb.h @@ -46,7 +46,7 @@
- This is the timeout to allow for submitting an urb in ms. We
allow
more
- time for a BULK device to react - some are slow.
*/ -#define USB_TIMEOUT_MS(pipe) (usb_pipebulk(pipe) ? 5000 : 100) +#define USB_TIMEOUT_MS(pipe) (usb_pipebulk(pipe) ? 5000 : 500)
This looks global change, how will it affect other implementations?
I dunno, that's why it's RFC. ;-) It's a timeout, so it *shouldn't* adversely affect other systems with well behaved usb chipsets. And boards will ill-tempered usb chipsets should work better. But I'm not familiar enough with the usb code to say that definitively.
I could try doing a dreamplug-specific hack to make it work, but if there's no adverse affect to other systems, then this is a cleaner approach.
You can post this standalone patch, remove from this patch series since it will be acked/applied by other custodian.
Based on new info (the OpenRD-ultimate is experiencing the same bug), a git bisect has revealed the following patch as the culprit:
commit c2dd0d45540397704de9b13287417d21049d34c6 Author: Aneesh V aneesh@ti.com Date: Thu Jun 16 23:30:49 2011 +0000
armv7: integrate cache maintenance support
- Enable I-cache on bootup - Enable MMU and D-cache immediately after relocation - Do necessary initialization before enabling d-cache and MMU - Changes to cleanup_before_linux() - Make changes according to the new framework
Signed-off-by: Aneesh V aneesh@ti.com
The reporter was also able to verify that reverting this patch fixed reading from the internal usb attached microsd card. I'd be lying if I said I understood how.
I think the problem is in one of two areas. Either the patch is incorrect, or it's fix highlighted a bug in the marvell EHCI code. I'll add some folks to the CC who can add more intelligent thoughts. :-)
You can see his error report here [1] which is the exact same error messages I was trying to fix after giving the command 'usb start'.
thx,
Jason.
[1] http://lists.denx.de/pipermail/u-boot/2011-July/097333.html