Hi,
On Sun, Jun 22, 2014 at 10:39:07AM -0400, Alan Stern wrote:
> > What happens if you attach the full-speed device to a high-speed hub
> > and plug that hub into the MUSB?
> >
> >
> > That's a very interesting test i will definitely do. Unfortunately, even
> > if that solves the problem, we could not use that on our production
> > boards because we cannot change the design, we are very advanced and
> > nearly approaching the production phase. We have no chance of changing
> > any hardware, it should be a software solution.
> >
> > I'm also very interested in any opinions about my assumptions because I
> > really don't know if I'm misunderstanding something and the problem
> > could be on any other place.
> >
> > Basically that assumptions were that we are sending too small packets
> > (64B) which combines with the interrupt latencies and the degraded
> > performance of MUSB as it has more work done in software than an EHCI
> > interface. So for reaching the required 0.5MB/s by reducing the time
> > spent on the OMAP micro (which i find difficult) or by increasing the
> > packet size, having to use the Isochronous interface with a risk of
> > packet losing.
>
> I don't know much about the details of the MUSB driver. Your
> assumption seems reasonable, though.
I must say, it's been years since I last tested full speed with musb,
but one thing to keep in mind is that MUSB's internal DMA engine (the
inventra dma engine) is pretty stupid and you end up having to program
each, in your case, 64B packet instead of starting a block transfer.
That's because mode1 DMA (Mentor's parlance for a 'block transfer') is
very quirky.
I would suggest using the kernel's function profiler to figure out where
most of the time is spent and trying to optimize that part of the code.
One thing I must ask, are you processing your packets in during
giveback? You might want to try setting HCD_BH flag if that's the case.
I just noticed that we missed sending that patch upstream. Here it is
and I'll send it formally soon if it helps you out, with your Tested-by
tag.
From 8027f584b4405902b7ec890841aa6c7b8ebd6161 Mon Sep 17 00:00:00 2001
From: George Cherian <george.cherian@xxxxxx>
Date: Wed, 5 Mar 2014 14:01:43 +0530
Subject: [PATCH] usb: musb: musb_host: Enable HCD_BH flag to handle urb return
in bottom half
Enable HCD_BH flag for musb host controller driver.
This improves the MSC/UVC through put. With this enabled
even 640x480@30fps webcam streaming is also supported.
Signed-off-by: George Cherian <george.cherian@xxxxxx>
Signed-off-by: Felipe Balbi <balbi@xxxxxx>
---
drivers/usb/musb/musb_host.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index eb06291..bc3b28c 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2612,7 +2612,7 @@ static const struct hc_driver musb_hc_driver = {
.description = "musb-hcd",
.product_desc = "MUSB HDRC host driver",
.hcd_priv_size = sizeof(struct musb *),
- .flags = HCD_USB2 | HCD_MEMORY,
+ .flags = HCD_USB2 | HCD_MEMORY | HCD_BH,
/* not using irq handler or reset hooks from usbcore, since
* those must be shared with peripheral code for OTG configs
--
2.0.0.390.gcb682f8
ps: which kernel are you using ?
--
balbi
Attachment:
signature.asc
Description: Digital signature
