AM335x SDK6/7 kernel: USB isochronous with DMA patches, known issues

Gunter,

Gunter Schmer said:

On the other side we have just released the latest SDK7 with L3.12. Could you let us know what known issues there may be with isochronous and DMA mode for the SDK7 and whether we have this fully tested?

I am checking on what has been validated for ISO and will get back to you once I have update.

Gunter Schmer said:

Could you let us know what possible issues we may run into with the L3.8 from the above, potentially not having critical patches?

We are not able to comment on this 3.8 kernel, since the last kernel before 3.12 we support is 3.2. We don't know who contributed the usb dma driver for the L3.8 kernel you referred.

I just tried to SDK7 prebuilt binaries and rootfs on my BeagleBoneBlack.

However, UVC Video 640x480 is still not working.

Yavta output 160x120:

0 (0) [-] 0 38400 bytes 90.841829 1396862251.520308
1 (1) [-] 1 38400 bytes 90.875728 1396862251.552850
2 (2) [-] 2 38400 bytes 90.908170 1396862251.586966
3 (3) [-] 3 38400 bytes 90.942091 1396862251.619473
4 (4) [-] 4 38400 bytes 90.974825 1396862251.653588

Yavta output 320x240:

0 (0) [-] 0 153600 bytes 143.608305 1396862304.285603
1 (1) [-] 1 153600 bytes 143.641715 1396862304.318139
2 (2) [-] 2 153600 bytes 143.675176 1396862304.350531
3 (3) [-] 3 153600 bytes 143.708552 1396862304.386777
4 (4) [-] 4 153600 bytes 143.742270 1396862304.419150

Yavta output 640x480 (614400 bytes)

NOT WORKING

Yavta does not output anything, however the DMA controller is receiving interrupts

/proc/interrupts

33:     527470      INTC  17  47400000.dma-controller

.. wait a few sec

33:     567305      INTC  17  47400000.dma-controller

.. wait a few sec

33:     615124      INTC  17  47400000.dma-controller


Is there a fix available that allows to capture at 640x480 in YUYV mode (so 614400 bytes per frame! not JPEG)

WIth kind regards,

Mathijs

Hi Mathijs,

Gstreamer is in the SDK prebuilt filesystem. I used the following gst pipeline to test VGA streaming.

gst-launch -v v4l2src device=/dev/video0 num-buffers=60 ! \
        'video/x-raw-yuv,width=640,height=480' ! \
        fakesink

I will give Yavta a try and get you back.

Mathijs,

What webcam do you use? What is the yavta command line?

I have no issue to get 640x480 resolution with Logitech pro9000.

root@am335x-evm:~# ./yavta --capture=10 -f YUYV -t 1/30 /dev/video0
Device /dev/video0 opened.
Device `UVC Camera (046d:0990)' on `usb-musb-hdrc.1.auto-1' is a video capture
 (without mplanes) device.
Video format set: YUYV (56595559) 640x480 (stride 1280) buffer size 614400
Video format: YUYV (56595559) 640x480 (stride 1280) buffer size 614400
Current frame rate: 1/15
Setting frame rate to: 1/30
Frame rate set: 1/30
8 buffers requested.
length: 614400 offset: 0 timestamp type/source: monotonic/EoF
Buffer 0/0 mapped at address 0xb6efb000.
length: 614400 offset: 614400 timestamp type/source: monotonic/EoF
Buffer 1/0 mapped at address 0xb6e65000.
length: 614400 offset: 1228800 timestamp type/source: monotonic/EoF
Buffer 2/0 mapped at address 0xb6dcf000.
length: 614400 offset: 1843200 timestamp type/source: monotonic/EoF
Buffer 3/0 mapped at address 0xb6d39000.
length: 614400 offset: 2457600 timestamp type/source: monotonic/EoF
Buffer 4/0 mapped at address 0xb6ca3000.
length: 614400 offset: 3072000 timestamp type/source: monotonic/EoF
Buffer 5/0 mapped at address 0xb6c0d000.
length: 614400 offset: 3686400 timestamp type/source: monotonic/EoF
Buffer 6/0 mapped at address 0xb6b77000.
length: 614400 offset: 4300800 timestamp type/source: monotonic/EoF
Buffer 7/0 mapped at address 0xb6ae1000.
0 (0) [-] 0 614400 bytes 475.611752 475.647911 1.615 fps
1 (1) [-] 2 614400 bytes 475.745147 475.778242 7.497 fps
2 (2) [-] 3 614400 bytes 475.811560 475.845091 15.057 fps
3 (3) [-] 4 614400 bytes 475.878104 475.912169 15.028 fps
4 (4) [-] 5 614400 bytes 475.944660 475.978892 15.025 fps
5 (5) [-] 6 614400 bytes 476.011683 476.046231 14.920 fps
6 (6) [-] 7 614400 bytes 476.078408 476.113316 14.987 fps
7 (7) [-] 8 614400 bytes 476.144714 476.179930 15.082 fps
8 (0) [-] 9 614400 bytes 476.210932 476.246679 15.102 fps
9 (1) [-] 10 614400 bytes 476.277350 476.313413 15.056 fps
Captured 10 frames in 1.320991 seconds (7.570073 fps, 4651052.612692 B/s).

Dear Bin Lui,

The webcams that i use are OEM modules with chipsets: AU3820 and AVEO A318S. They are capable of 640x480 capture with 30fps with UVC support.

My output gives the following result:

root@am335x-evm::~# ./yavta --capture=10 -f YUYV -t 1/30 /dev/video0
Device /dev/video0 opened.
Device `USB Video Device' on `usb-musb-hdrc.1.auto-1' is a video capture device.
Video format set: YUYV (56595559) 640x480 (stride 1280) buffer size 614400
Video format: YUYV (56595559) 640x480 (stride 1280) buffer size 614400
Current frame rate: 1/30
Setting frame rate to: 1/30
Frame rate set: 1/30
8 buffers requested.
length: 614400 offset: 0
Buffer 0 mapped at address 0xb6d43000.
length: 614400 offset: 614400
Buffer 1 mapped at address 0xb6cad000.
length: 614400 offset: 1228800
Buffer 2 mapped at address 0xb6c17000.
length: 614400 offset: 1843200
Buffer 3 mapped at address 0xb6b81000.
length: 614400 offset: 2457600
Buffer 4 mapped at address 0xb6aeb000.
length: 614400 offset: 3072000
Buffer 5 mapped at address 0xb6a55000.
length: 614400 offset: 3686400
Buffer 6 mapped at address 0xb69bf000.
length: 614400 offset: 4300800
Buffer 7 mapped at address 0xb6929000.
Warning: bytes used 82976 != image size 614400
0 (0) [-] 4087 82976 bytes 79946.397622 79946.399844 0.001 fps
Warning: bytes used 116464 != image size 614400
1 (1) [-] 9181 116464 bytes 80964.945771 80964.949518 0.001 fps
Warning: bytes used 90104 != image size 614400
2 (2) [-] 12445 90104 bytes 81617.523119 81617.525384 0.002 fps

When i add the 'modprobe uvcvideo quirks=0x80 nodrop=1 timeout=5000' i get parts of the image, but corrupted (white dot at the end of the buffer). This .NET app is just a test application to show the picture on my screen. It works fine with 320x240).

Might is be that the URB data is corrupted somehow, or that the packet length is reported incorrectly?

512 bytes / 1024 bytes isochronous packets(

I'll try to obtain an Logitech Quickcam Pro C9000, to see if i can get similar results

Kind regards,

Mathijs

Dear Bin Liu,

Finally i've managed to get my hands on a  Logitech Quickcam pro C9000 camera.

With the new SDK7 on a BBB, your yavta output gives a different result then mine.

 

15 FPS

root@am335x-evm:~# ./yavta --capture=10 -f YUYV -t 1/15 /dev/video0
Device /dev/video0 opened.
Device `UVC Camera (046d:0809)' on `usb-musb-hdrc.1.auto-1' is a video capture device.
Video format set: YUYV (56595559) 640x480 (stride 1280) buffer size 614400
Video format: YUYV (56595559) 640x480 (stride 1280) buffer size 614400
Current frame rate: 1/30
Setting frame rate to: 1/15
Frame rate set: 1/15
8 buffers requested.
length: 614400 offset: 0
Buffer 0 mapped at address 0xb6e68000.
length: 614400 offset: 614400
Buffer 1 mapped at address 0xb6dd2000.
length: 614400 offset: 1228800
Buffer 2 mapped at address 0xb6d3c000.
length: 614400 offset: 1843200
Buffer 3 mapped at address 0xb6ca6000.
length: 614400 offset: 2457600
Buffer 4 mapped at address 0xb6c10000.
length: 614400 offset: 3072000
Buffer 5 mapped at address 0xb6b7a000.
length: 614400 offset: 3686400
Buffer 6 mapped at address 0xb6ae4000.
length: 614400 offset: 4300800
Buffer 7 mapped at address 0xb6a4e000.
0 (0) [-] 0 614400 bytes 359.828537 359.894462 0.578 fps
1 (1) [-] 1 614400 bytes 359.895117 359.961867 15.020 fps
2 (2) [-] 2 614400 bytes 359.961613 360.029460 15.038 fps
3 (3) [-] 3 614400 bytes 360.027140 360.096344 15.261 fps
4 (4) [-] 4 614400 bytes 360.093510 360.160689 15.067 fps
5 (5) [-] 5 614400 bytes 360.159357 360.228315 15.187 fps
6 (6) [-] 6 614400 bytes 360.228345 360.295455 14.495 fps
7 (7) [-] 7 614400 bytes 360.293047 360.362964 15.455 fps
8 (0) [-] 8 614400 bytes 360.361783 360.430476 14.548 fps
9 (1) [-] 9 614400 bytes 360.427679 360.493697 15.175 fps
Captured 10 frames in 2.395369 seconds (4.174722 fps, 2564948.970716 B/s).
8 buffers released.

30FPS

root@am335x-evm:~# ./yavta --capture=10 -f YUYV -t 1/30 /dev/video0
Device /dev/video0 opened.
Device `UVC Camera (046d:0809)' on `usb-musb-hdrc.1.auto-1' is a video capture device.
Video format set: YUYV (56595559) 640x480 (stride 1280) buffer size 614400
Video format: YUYV (56595559) 640x480 (stride 1280) buffer size 614400
Current frame rate: 1/30
Setting frame rate to: 1/30
Frame rate set: 1/30
8 buffers requested.
length: 614400 offset: 0
Buffer 0 mapped at address 0xb6f2d000.
length: 614400 offset: 614400
Buffer 1 mapped at address 0xb6e97000.
length: 614400 offset: 1228800
Buffer 2 mapped at address 0xb6e01000.
length: 614400 offset: 1843200
Buffer 3 mapped at address 0xb6d6b000.
length: 614400 offset: 2457600
Buffer 4 mapped at address 0xb6cd5000.
length: 614400 offset: 3072000
Buffer 5 mapped at address 0xb6c3f000.
length: 614400 offset: 3686400
Buffer 6 mapped at address 0xb6ba9000.
length: 614400 offset: 4300800
Buffer 7 mapped at address 0xb6b13000.

-- SILENCE --

Another thing is, that when i use MJPEG, the image in the buffers is often corrupted. when is disable the DMA (MUSB_PIO), the jpeg image is fine!

It seems like there are two issues:

- Isochronous DMA is not working properly (corrupts databuffer)

- USB Transfer bandwidth is limited to ~9.8 Mbytes/sec. For 640x480 30fps YUYV i would need at least 18Mbytes.

 

I did some tests with an Beaglebone XM (Containing an DM3730 SoC) and USB camera is working without issues (maximum i could get from C9000 webcam is 24Mbytes/sec when using 800x600x25fps YUYV)

 

Could it be that the USB DMA is broken on the AM335X? or maybe a buggy driver?

 

Kind regards,

 

Mathijs

 

Mathijs,

I noticed Yavta and Gstreamer gave different results. I have one or two webcams, with which Yavta only captures a few frames then stops, but Gstreamer is able to capture continuously.

The USB DMA is newly developed in the mainline kernel 3.12. I guess this could be issues in the driver that cause the driver does not properly handle different USB requests from the upper layer.

If you don't mind to use a older kernel, the AM335x SDK download webpage has a link to the previous SDK 6.0, which has kernel 3.2. This kernel has been used for many years, and its USB DMA is mature.

Dear Bin Liu,

I just made an SD card with the SDK6.0 including the 3.2 kernel/u-boot and filesystem.

Guess what:

root@am335x-evm:~# ./yavta --capture=10 -f YUYV -t 1/30 /dev/video0
Device /dev/video0 opened: UVC Camera (046d:0809) (usb-musb-hdrc.1-1).
Video format set: width: 640 height: 480 buffer size: 614400
Video format: YUYV (56595559) 640x480
Current frame rate: 1/30
Setting frame rate to: 1/30
Frame rate set: 1/30
8 buffers requested.
length: 614400 offset: 0
Buffer 0 mapped at address 0x40117000.
length: 614400 offset: 614400
Buffer 1 mapped at address 0x40293000.
length: 614400 offset: 1228800
Buffer 2 mapped at address 0x40395000.
length: 614400 offset: 1843200
Buffer 3 mapped at address 0x40511000.
length: 614400 offset: 2457600
Buffer 4 mapped at address 0x4060a000.
length: 614400 offset: 3072000
Buffer 5 mapped at address 0x4079b000.
length: 614400 offset: 3686400
Buffer 6 mapped at address 0x40910000.
length: 614400 offset: 4300800
Buffer 7 mapped at address 0x40a21000.
0 (0) [-] 0 614400 bytes 561.816434 1372202292.210321
1 (1) [-] 1 614400 bytes 562.182004 1372202292.246241
2 (2) [-] 2 614400 bytes 562.216550 1372202292.278254
3 (3) [-] 3 614400 bytes 562.249203 1372202292.310175
4 (4) [-] 4 614400 bytes 562.281888 1372202292.342707
5 (5) [-] 5 614400 bytes 562.316495 1372202292.378168
6 (6) [-] 6 614400 bytes 562.349118 1372202292.410181
7 (7) [-] 7 614400 bytes 562.381833 1372202292.442591
8 (0) [-] 8 614400 bytes 562.414456 1372202292.478235
9 (1) [-] 9 614400 bytes 562.449094 1372202292.510248
Captured 9 frames in 0.300385 seconds (29.961549 fps, 20453751.019525 B/s).
8 buffers released.
root@am335x-evm:~#

SDK 6 is able to do 30fps without any problems!

However, i strongly demand on the 3.12 kernel due to other things that have been fixed in the last years.

Will this be fixed? Is this problem already identified? are there any patches that i can apply to the kernel?

With kind regards,

Mathijs

Mathijs,

Thanks for the update. Our PSP development team continues working on improving the software support on AM335x devices.

I have already reported this issue to the team, but we have not identify this issue and don't have solution yet.

any news about this ? => I think it is still broken ...
is there a fix ?

AMSDK8.0 (3.14 kernel) has been released last week. Can you please check if the issue still exists in kernel 3.14?

Thxs for your reply.

Well the 3.14 kernel is a little better but the performance is not as good as I would expect.

Before I was getting around 10MB/s reading from my USB flash drive.  Now it is about 14MB/s.

For reference, my RPi (with the same flash drive) is almost 21MB/s.

Are there any kernel/module parameters for optimization ??

thanks again,

I keeps reading this forum and this specific thread,

in order to find an answer referring the unsolved problem:

web-cam capturing UVC raw data while using 640x480 camera mode, Pixel Format: 'YUYV'


Here in this forum, there was an assumption that the DMA transfer mode in the kernel driver, is buggy.
should I missed the solution/answer for it ?

regards

and thanks in advance

H.

The subject of this email thread is about webcam, but your question is about thumb drive throughput. And the original E2E thread has three different customers and one Tier posting about the two different USB topics (webcam & thumb driver).

Could you please clarify what USB issue is?

Hello rogerio 

The BBB (kernel 3.8.13-bone32) is connected to a webcam

 (e.g. Logitech C170 / Logitech C210 / Microsoft LifeCam VX-800) via its USB port

Small C app. set the camera to a streaming YUYV mode , while occasionally we capture/freeze  still image .

later on we try to find certain objects (image processing), hence we need exactly 640x480 resolution.

In that setup the webcam stream run via DMA.

The 3 webcam above, are still working while connected to an SOC 8200 ( our previous platform and old kernel) .

BUT any one of the above webcam connected to  BBB, fails to stream (hence capture images).

Obviously, all three do support YUYV 640x480 mode :
Webcam C170
root@BBB1:/sbin# v4l2-ctl -d /dev/video0 --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
Index : 0
Type : Video Capture
Pixel Format: 'YUYV'
Name : YUV 4:2:2 (YUYV)
Size: Discrete 640x480
Interval: Discrete 0.033 s (30.000 fps)
Interval: Discrete 0.067 s (15.000 fps)
Size: Discrete 352x288
Interval: Discrete 0.033 s (30.000 fps)
Interval: Discrete 0.067 s (15.000 fps)
Size: Discrete 320x240
Interval: Discrete 0.033 s (30.000 fps)
Interval: Discrete 0.067 s (15.000 fps)

Logitech C210 :
root@BBB1:/sbin# v4l2-ctl -d /dev/video0 --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
Index : 0
Type : Video Capture
Pixel Format: 'YUYV'
Name : YUV 4:2:2 (YUYV)
Size: Discrete 640x480
Interval: Discrete 0.033 s (30.000 fps)
Interval: Discrete 0.040 s (25.000 fps)
Interval: Discrete 0.050 s (20.000 fps)
Interval: Discrete 0.067 s (15.000 fps)
Interval: Discrete 0.100 s (10.000 fps)
Interval: Discrete 0.200 s (5.000 fps)

Microsoft LifeCam VX-800

v4l2-ctl -d /dev/video0 --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
Index : 0
Type : Video Capture
Pixel Format: 'YUYV'
Name : YUV 4:2:2 (YUYV)
Size: Discrete 640x480
Interval: Discrete 0.033 s (30.000 fps)

I hope the above details clarifies the webcam problem

many thanks in advance

H.

HST,

The issue you described (UVC streaming on/off back and forth) is similar to an issue we identified recently, in which gstreamer pipeline streaming on/off freezes. The issue is under investigation. I will keep you posted once we have progress.

Bin Liu,

It is great news to hear that TI guys are working on it.

Since that thread was opened back then on Apr-2014,

and we are relying on TI-support for having a solution and quick as possible.

Please, do not hasitate and send us a possible/beta solution, We are suggesting our testing capabilities for a possible/beta solution, too

and again, many thanks in advance

H.S.T.

HST,

Thanks for the understanding. I will update once we have progress on the investigation.

The original issue in this thread is different from what you reported.

The original issue was that Yavta was unable to stream video consistantly, but Gstreamer does not have the problem. According to the discussion in this thread, this issue is fixed in AMSDK8.0.

But the problem you reported is CPPI DMA hangs when turn on/off video streaming back and forth, this is more like DMA channel teardown issue.

Hi,

I have the same problem in using camera with resolution at higher than 320x240.
I see this problem only on am335x processor with these kernels: bbb-v3.8.13 , ti-sdk-v3.12 , ti-sdk-3.14.43 and bbb-3.14.49.

I tested my vision applications includes real time Face Detection/Recognition with Qt+OpenCV and still images capture by uvccapture on many processors such as: ti DM3730, freescale imx.6 dual, atmel SAM9G45 and Nvidia Tegra2 at any image resolutions without any problems.

The only kernel that works OK on am335x is 3.2 that i tested on BeaglBone Black and MYD-AM335x boards.

My Test results with 3 different camera and different kernels are:
CAM8100-U : V3.2 ok but V3.8, V3.12 and V3.14 failed.
A4TECH PK-333E : V3.2 ok but V3.8, V3.12 and V3.14 failed.
MICROSOFT LifeCam Cinema HD : V3.2 ok but V3.8, V3.12 and V3.14 failed.

I'm tried hacking v3.8 musb driver from v3.2 source but no success.
I'm going to test my apps on the Rico Board that equipped with ti AM437x processor and kernel 3.14 after i received the board

I'm confused! why this problem still exists in newest published kernal from beaglbone and ti?
This problem can affect using am335x in our products, so i'm very happy if problem resolved.

HST,

Please try the following patch. It adds 50us delay after turn off CPPI during channel teardown.

diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index 190a3f8..40947da 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -582,6 +582,9 @@ static int cppi41_dma_channel_abort(struct dma_channel *channel)
        } else {
                cppi41_set_autoreq_mode(cppi41_channel, EP_MODE_AUTOREQ_NONE);

+               /* delay to drain to cppi dma pipeline for isoch */
+               udelay(50);
+
                csr = musb_readw(epio, MUSB_RXCSR);
                csr &= ~(MUSB_RXCSR_H_REQPKT | MUSB_RXCSR_DMAENAB);
                musb_writew(epio, MUSB_RXCSR, csr);

Bin Liu,

thanks,

Could you plz supply me with link to the kernel which is relevant to this patch ?

since we tried to use 3.14 from Robert Nelson's repo. , and it seems to have quite few changes relative to TI's repo.

HST

HST,

This patch is based on AM335x AMSDK 8.0 (http://software-dl.ti.com/sitara_linux/esd/AM335xSDK/08_00_00_00/index_FDS.html), plus patches #8.3 from http://processors.wiki.ti.com/index.php/Sitara_Linux_MUSB_Issues.

Hi,
thanks Bin Liu,
I see this modification in musb driver of BBB kernel-4.1.4 at git repository.
I test that version as soon as possible and feedback here.
Rama

Rama,

Can you please let me know the link of the BBB kernel-4.1.4 repo? I'd like to check who posted the similar patch.

Testing failed with the same results (as my older post) on linux kernel 4.1.4 from below link:
github.com/.../linux

and udalay(50) patch exist in the next file:
github.com/.../musb_cppi41.c

I test linux-4.1.4 with next programs with 3 type camera:
- uvccapture v0.5-ac1 => app hanged
- yavta final version => app hanged
-gst-launch v1.0 => failed
- luvc-test final version => app hanged
- framegrabber -v1.0 => select timeout
- capture v1.3 => select timeout

so this patch can't resolve my problems.

Rama,

rama shouti said:

and udalay(50) patch exist in the next file:
github.com/.../musb_cppi41.c

The delay you referred is at line #559. My patch adds another delay between line #552 and #554.

Can you please re-cap the issue you have? Does your test failed at the very first run? or after a few iterations?

If latter, my patch suppose to fix it; but if former, I just noticed there seems to be a regression since TI SDK8.0 - I have a couple webcams which worked in SDK7 with VGA resolution, but they stopped working in SDK8. I will try to find out which kernel change causes this regression.

I've applied the patches as well, and i got the same results:

640x480: not working

320x240: working

Also, the 3.2 kernel DOES work, but since 3.8 the DMA is broken. I've tested with the 4.1.2 kernel and it is still broken:

Tested so far:

UVC Camera  ( 640x480 YUYV, isochronous endpoint) not working

GSPCA Camera (PS3 Eye 640x480 YUYV bulk endpoint) not working

USB Memory drive -> about 10Mbyte/sec transfer working

My conclusion so far is that the problem should be in the cppi41 or musb driver and applies for both bulk and isoc.

I really hope someone will fix this behavior, so i can use DMA instead of PIO mode.

Kind regards,

Mathijs

My camera can do MPJEG and YUYV, with the following settings (for YUYV)

Format 1: YUYV (56595559)
Type: Video capture (1)
Name: YUV 4:2:2 (YUYV)
Frame size: 1280x720 (1/10)
Frame size: 800x600 (1/10)
Frame size: 640x480 (1/30, 1/20, 1/15, 1/8)
Frame size: 640x360 (1/30, 1/20, 1/15, 1/8)
Frame size: 352x288 (1/30, 1/20, 1/15, 1/8)
Frame size: 320x240 (1/30, 1/20, 1/15, 1/8)
Frame size: 160x120 (1/30, 1/20, 1/15, 1/8)

I tried 640x480 1/30: fail
I tried 640x480 1/20: fail
I tried 640x480 1/8: fail
I tried 640x360 1/20: fail
I tried 640x360 1/8: fail
I tried 352x288 1/30: working, but not stable framerate
I tried 352x288 1/8: working, but not stable framerate
I tried 320x240 1/30: working

Seems to be a framesize issue more then a total data / sec issue.


P.S. The suggestion that AM335x MUSB is not capable of doing 18Mb/s is new to me. I had no problems with the 3.2 kernel doing 640x480x30fps YUYV.

P.S.S. The reason that i dont like the MJPEG is because MJPEG stills get corrupted, and are not useable with DMA mode enabled.

P.S.S.S. When i do a file copy of 131 MB to /tmp with timing i get:

[root@xxxxxx boot]# time cp video.mp4 /tmp/video1

real 0m8.914s
user 0m0.020s
sys 0m2.120s

So about 14Mb/s, but that's a cheap USB flash drive that is not speed optimized.

Kind regards,

Mathijs,

Can you please open a new thread for your issue?

The problem you have seems to be different from all others in this thread. And this thread is already too long and has many posters, it is hard for me to track.

Ideally we want this forum to have exact one query in one thread. If there was any existing thread which could be related, the new thread can refer the links to the related threads.

Rama,

Were you confirming that you have tested your camera works on 640x480@20fps?

Each UVC camera is different, I found that Logitech C920 (046d:082d) can transfer 640x480@30fps to AM335x, because this camera has much shorter setup time in each video frame and starts sending video data packet much quicker after received the transfer request from the USB host than other cameras I have, so it has much more time to send the whole VGA frame until the 33ms elapses.

Finally i got my Rico Board MYS-437X and test my applications on it with the linux-3.12.10-ti2013.12.01.
all my 3 cameras worked ok in DMA and PIO only modes at 640x480 and above without any problems at long time test (> 5 hour).

this kernel can be used for am335x BBB board. so i boot my BBB with this kernel.
and result: the cameras only work with 320x240 same as other kernel versions.

my conclusion is, both am335x and am437x used the same usb drivers in the linux-3.12.10-ti2013.12.01,
and the am437x doesn't have any problems with resolution above 320x240 but am335x has.
so this can be a bug in the usb driver with the hardware of am335x.

rama shouti said:

But my cameras doesn't work in both DMA and PIO only modes in kernel 3.8 at 640x480 pixels and above.

does your test ok at 640x480 with 3.8 kernel and PIO mode only?

Do you mean 640x480@30fps? It requires about 18MB/s USB throughput, but PIO mode can only archive about 5~6MB/s, so PIO mode cannot support 640x480@30fps.

BTY, 3.8 kernel is not supported by TI, I did not test on 3.8 kernel.

rama shouti said:

I don't have any problems with 3.2 kernel at 640x480 frame capture.

There are two major differences between 3.2 and 3.12+ kernels, in term of USB performance.

- 3.12 kernel has system performance regression in general, comparing to 3.2 kernel, due to module framework change, SMP support, and many other factors;

- the MUSB CPPI DMA driver in 3.12+ is completely rewritten, and now the driver is under dmaengine framework, it is completely different from the CPPI driver in 3.2 kernel. The 3.12 CPPI driver has performance regression in general. TI is working on improving the CPPI driver performance.

rama shouti said:

Finally i got my Rico Board MYS-437X and test my applications on it with the linux-3.12.10-ti2013.12.01.
all my 3 cameras worked ok in DMA and PIO only modes at 640x480 and above without any problems at long time test (> 5 hour).

How did you test PIO mode on AM437x? It does not have a configuration for PIO mode.

rama shouti said:

my conclusion is, both am335x and am437x used the same usb drivers in the linux-3.12.10-ti2013.12.01,

AM335x and AM437x do not use the same USB driver. AM335x has MUSB controller, but AM437x has DWC3 controller, both controllers are completely different hardware.