Hi Frederik, On Fri, May 10, 2013 at 2:22 PM, Frederik Schmid <frederik.schmid@xxxxxxxxx> wrote: > Hi Ruslan, > > Thanks for the tips! A few comments below: > > On Friday 10 May 2013 13.54.53 Ruslan Bilovol wrote: >> Hello Frederic, >> >> On Fri, May 10, 2013 at 12:54 PM, Frederik Schmid >> >> <frederik.schmid@xxxxxxxxx> wrote: >> > Well, my conclusion is that this setup, IDS-camera + musb, is horribly >> > sensitive to interrupt latency. >> > >> > If the musb-interrupt is blocked for ~100us the pipe is stalled. Most of >> > the interrupts on my target were routed to CPU0 while CPU1 had few. >> > >> > When I re-route the musb interrupts to CPU1 throughput increases to >> > ~120Mbps but I've only reduced the probability of the interrupt being >> > blocked. >> If you want to increase throughput over musb on omap4, usually next steps >> help: - route musb IRQ to another CPU if possible > > Done that. > >> - check if musb uses DMA mode (not PIO) > > It does. > >> - check if the data (urb) passed to musb is aligned, if not - apply next >> patch: >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id= >> 8408fd1d83e39bf856d31a36b70bcc53527702fd - play with double packet buffering > > Didn't check but I applied your patch anyway. Doesn't seem to make any > difference. > >> - increase OPP - this will reduce latency > > I'm not sure what this means. Something to do with power management? Is there > something specific I could try? yes. here is some documentation about it: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/power/opp.txt Regards, Ruslan > >> >> But I can say that on OMAP4 throughput over musb will be lower than >> over ehci controller because >> ehci one does many things in HW whereas musb have to do some of them in SW. >> My scores for musb were ~145 Mbits/s for bulk transfers, but they >> probably may be increased after additional tuning. >> >> > The only hope this application has is if MODE1 in the controller could >> > alleviate latency dependence but MODE1 seems quite broken in the hardware? >> > >> > musb_host.c: >> > >> > /* Disadvantage of using mode 1: >> > * It's basically usable only for mass storage class; essentially all >> > * other protocols also terminate transfers on short packets. >> > * ... >> > */ >> > >> > Best regards, >> > Frederik >> > >> > On Friday 10 May 2013 07.26.35 Frederik Schmid wrote: >> >> Hi Greg, >> >> >> >> The kernel is based on 3.4.11 from omapzoom.org (ti-ubuntu-3.4-1487) with >> >> Variscite BSP patches from: >> >> >> >> http://www.variwiki.com/index.php?title=VAR-SOM-OM44_-_Ubuntu_Precise >> >> >> >> I was expecting 200-250Mbps which is entirly possible on the same chip >> >> using its ehci-controller. musb seems to sustain this speed also, for >> >> most of the time, until a "glitch" like the one in the screenshot stalls >> >> the pipe. >> >> >> >> We don't want to use the ehci-controller because it's already bogged down >> >> with an ethernet controller. >> >> >> >> Regards, >> >> Frederik >> >> >> >> On Thursday 09 May 2013 08.12.47 Greg KH wrote: >> >> > On Thu, May 09, 2013 at 10:44:05AM +0200, Frederik Schmid wrote: >> >> > > Hi, >> >> > > >> >> > > I'm developing a camera application on a TI OMAP4460. I have a cmos >> >> > > usb-camera from IDS (UI-1551-LE-C-HQ) connected to the OTG-port (musb >> >> > > as >> >> > > host) on the OMAP. >> >> > > >> >> > > I get very poor frame rates with this setup reliably. The throughput >> >> > > rate >> >> > > is ~50-70Mbps. (1600x1200,8bpp,3-5fps) >> >> > > >> >> > > I uploaded a screenshot of a packet trace here: >> >> > > >> >> > > http://i.imgur.com/26XL23T.png >> >> > > >> >> > > The host seems to keep up with the camera most of the time but >> >> > > occasionally >> >> > > some kind of "glitch" causes the host to lag behind and the camera >> >> > > signals >> >> > > STALL because of buffer overrun. >> >> > >> >> > What kernel version are you using? And what data rate do you expect to >> >> > be getting with this hardware configuration? >> >> > >> >> > thanks, >> >> > >> >> > greg k-h >> >> >> >> -- >> >> To unsubscribe from this list: send the line "unsubscribe linux-usb" in >> >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > >> > -- >> > To unsubscribe from this list: send the line "unsubscribe linux-usb" in >> > the body of a message to majordomo@xxxxxxxxxxxxxxx >> > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
