Linux/DRA744: VIP: video capture does not always start

Francesco Valla

Part Number: DRA744

Tool/software: Linux

Hi,

I'm using the VIP block to acquire images from multiple cameras, using a custom application based on TI's dmabuftest.

Sometimes one of the acqusitions does not start (while the others work fine). Debugging the issue, I discovered that the application hangs at VIDIOC_DQBUF ioctl, waiting indefinitely for a buffer to arrive. This happens on K4.4 both with the latest version of the VIP driver (processor-sdk-linux-automotive-3.02.00.03) and with older ones (for example processor-sdk-linux-automotive-3.00.00.03).

In kernel 3.14 it just worked fine.

Please note that this happens with multiple models of cameras, both with discrete and embedded sync signals.

Any help will be appreciated.

Regards,

Francesco

over 6 years ago

0 Yordan Kamenov over 6 years ago

TI__Mastermind 42515 points

Hi Francesco,

I have forwarded your question to a VIP expert.

Regards,
Yordan

0 Nikhil Devshatwar over 6 years ago

TI__Genius 9905 points

Hello

From application point of view, DQBUF is a blocking ioctl, which blocks untill driver returns a frame.
If you see that there is some case where there is a hang.
Please attach the register dump of the entire VIP and VPDMA module.

Also answer following:
- Does this occur with dmabuftest?
- Does hang happen on the first frame only or sometimes after the capture has started (runtime)
- Does killing and relaunching app works

Nikhil D

0 Francesco Valla over 6 years ago in reply to Nikhil Devshatwar

Intellectual 570 points

Hi Nikhil,
here are the register dumps:

working: pastebin.com/.../K8zLWp8W
not working: pastebin.com/.../Cn8bYbiL

As for your questions:

- Does this occur with dmabuftest?
Yes (dumps are with latest version of dmabuftest)

- Does hang happen on the first frame only or sometimes after the capture has started (runtime)?
The hang is only on first frame. If the stream starts, then the acquisition can run indefinitely without issues.

- Does killing and relaunching app works?
Yes, but sometimes more than one restart is required.

Moreover, it happens more frequently if multiple captures are started at the same time (but also with a single capture).

Thank you!

Br,
Francesco

0 Nikhil Devshatwar over 6 years ago in reply to Francesco Valla

TI__Genius 9905 points

Hello,

TI does not allow access to pastebin.com
Can you please post logs in http://pastebin.ubuntu.com/ OR attach them in this thread?

Regards,
NIkhil D

0 Francesco Valla over 6 years ago in reply to Nikhil Devshatwar

Intellectual 570 points

Hello,
here they are:

working: pastebin.ubuntu.com/.../
non-working: pastebin.ubuntu.com/.../

Br,
Francesco

0 Nikhil Devshatwar over 6 years ago in reply to Francesco Valla

TI__Genius 9905 points

Hi

Based on the register dumps, I see that the parrser is able to detect the video size in both cases (48995530)
But, the difference is in the VPDMA list state register(4899d00c)

In non working state, VPDMA list is NOT busy. (It should always be busy doing DMAs)

Also, VPDMA IRQ registers (4899d088) indicates that the capture has occured from 4 channels (List0,1,2,3) at least once.
But in non working case, strange enough, IRQ bit for List0 complete is set in VPDMA IRQ reg (4899d088) and it is enabled also (4899d08c)

But, it does not reflect in the toplevel IRQ regs(48990020)

Please answer few more questions:-
Are you running multiple captures when you see this failure?
If so, Can you confirm that the failure occurs ONLY if multiple captures are running paralllely OR does it happen with single capture also.

I suspect this might be the case of missing IRQ from CPU side.
Just try to run with only one capture and see if you can reproduce.
I'll conclude further based on your info

Nikhil D

0 Francesco Valla over 6 years ago in reply to Nikhil Devshatwar

Intellectual 570 points

Hi Nikhil,
I am seeing this issue both when doing single and multiple captures; it is however more frequent in multi-capture cases (in which often two or three captures over four run without problems).

Thank you

Br,
Francesco

0 Nikhil Devshatwar over 6 years ago in reply to Francesco Valla

TI__Genius 9905 points

Hi Francesco

Can you please attach the register dump where you ONLY run single capture from the start of the boot
Whenever you see the hang, dump registers and attach.

Do not change the device being used across different runs.

Nikhil D

0 Francesco Valla over 6 years ago in reply to Nikhil Devshatwar

Intellectual 570 points

Here it is:

pastebin.ubuntu.com/.../

(Using Vin4a)

Br,
Francesco

0 Nikhil Devshatwar over 6 years ago in reply to Francesco Valla

TI__Genius 9905 points

Hi Francesco,

As suspected, This actually is a case of the missing IRQ.
I can see that the VPDMA IRQ bit is set but the toplevel bit is not set correctly.

This can happen when the IRQ gets fired even before the IRQ was enabled by driver.

I think this is fixed in one of the patches.
Please provide the last TI commit ID of the kernel you are using, I can point out the patch which fixed this isuse.

Nikhil D

0 Francesco Valla over 6 years ago in reply to Nikhil Devshatwar

Intellectual 570 points

Hi,
latest commit from TI is 91222fb (tag: processor-sdk-linux-automotive-3.01.00.03).

Thank you

Francesco

0 Nikhil Devshatwar over 6 years ago in reply to Nikhil Devshatwar

TI__Genius 9905 points

Hi Francisco

Here is the patch which should fix the described issue.
pastebin.ubuntu.com/.../
Let me know if it helps.

Nikhil D

0 Francesco Valla over 6 years ago in reply to Nikhil Devshatwar

Intellectual 570 points

Hi Nikhil,
unfortunately, the patch did not solve our issue.

Is there any other path we can follow?

Thank you

Br,
Francesco

0 Nikhil Devshatwar over 6 years ago in reply to Francesco Valla

TI__Genius 9905 points

I am sorry to hear that. Can you please share the register dump AFTER applying the patch.? Nikhil D

0 Francesco Valla over 6 years ago in reply to Nikhil Devshatwar

Intellectual 570 points

Hi Nikhil,
since now I have not been able to replicate the issue in single-capture mode (so maybe a part of the issue is solved).

However, I am seeing it in multi-capture mode (multiple streams on a single port - V4L2_MBUS_BT656). The following dump is for such a configuration:

pastebin.ubuntu.com/.../

Thank you

Br,
Francesco

0 Nikhil Devshatwar over 6 years ago in reply to Francesco Valla

TI__Genius 9905 points

Fransisco,
Glad to know that part of the issue is solved.

I don't see anything obvious in the regdump, this looks like a case where the hardware is waiting for the capture to finish
(Which is most the case 99.9% of the time)

I see that the VPDMA IRQs are set (Which indicates at least one capture has occured)

Can you share more details about the multi capture failure situation:-
- Run multi capture usecase right after boot and check how many captures run?
- Does it run only 1,2, or more captures (How often something fails and how often is it reproducible?)
- When failed to capture, try to get the status of the VPDMA list N by running following

omapconf write 0x4899d000 0xdead000N
omapconf read 0x4899d000

Nikhil D

0 Francesco Valla over 6 years ago in reply to Nikhil Devshatwar

Intellectual 570 points

Hi Nikhil,
multi capture is already run right after boot. Number of successfully-running captures is not constant, and reproducibiity cannot be obtained in a deterministic manner.

VPDMA list status:

-bash-3.2# omapconf write 0x4899d000 0xdead0000
-bash-3.2# omapconf read 0x4899d000
00000026
-bash-3.2# omapconf write 0x4899d000 0xdead0001
-bash-3.2# omapconf read 0x4899d000
00000027
-bash-3.2# omapconf write 0x4899d000 0xdead0002
-bash-3.2# omapconf read 0x4899d000
00000028
-bash-3.2# omapconf write 0x4899d000 0xdead0003
-bash-3.2# omapconf read 0x4899d000
00000029
-bash-3.2# omapconf write 0x4899d000 0xdead0004
-bash-3.2# omapconf read 0x4899d000
000001FF
-bash-3.2# omapconf write 0x4899d000 0xdead0005
-bash-3.2# omapconf read 0x4899d000
000001FF
-bash-3.2# omapconf write 0x4899d000 0xdead0006
-bash-3.2# omapconf read 0x4899d000
000001FF
-bash-3.2# omapconf write 0x4899d000 0xdead0007
-bash-3.2# omapconf read 0x4899d000
000001FF

Thank you

Br,
Francesco

0 Nikhil Devshatwar over 6 years ago in reply to Francesco Valla

TI__Genius 9905 points

Francesco

From the dump, I can infer to conclusions.
All the VPDMA lists are busy waiting for the right channels.
This is indeed expected. I am not sure still why do you see the capture failre.

Can you just try to run on a newer processor SDK release?
See the behavior on the latest driver and check if is reproducible

Thanks
Nikhil D

Processors

Processors forum

Linux/DRA744: VIP: video capture does not always start