Cannot get the stream over mipi csi2 port

cancel
Showing results for 
Search instead for 
Did you mean: 

Cannot get the stream over mipi csi2 port

Jump to solution
610 Views
efecan_icoz
Contributor III

Hi all,

I am trying to implement this patch to my iMX8MM board but i hit the wall at capturing the data from the IC over MIPI CSI2 bus. Whenever i try to stream the content of IC i'm getting stuck at the "vidioc_dqbuf" ioctl. When i checked the contents of the ioctl at the driver side it calls "vb2_dqbuf" and application waits at "__vb2_wait_for_done_vb" in videobuf2 module. It's waiting for an event i suppose but this event never occurs. And vb2 module waits for it's buffer to be filled desparately to eternity.

How can i debug this situation ? Should i probe the CSI line to see if there is any data or clock on the bus or may it be some software issue ?

Here is the commands I've tried and their corresponding dmesg messages:

Via v4l2-ctl:

v4l2-ctl --set-fmt-video=width=720,height=480,pixelformat=YUYV --stream-mmap --stream-count=1 --stream-to=grab-yuyv.raw‍‍
[  319.330061] mx6s-csi 32e20000.csi1_bridge: csi v4l2 busfreq high request.
[  319.330261] mx6s-csi 32e20000.csi1_bridge: set to pixelformat 'YUYV-1'
[  319.379664] mx6s-csi 32e20000.csi1_bridge: count=4, size=0
[  319.379673] size=691200
[  319.381174] videobuf2_common: __setup_offsets: buffer 0, plane 0 offset 0x00000000
[  319.390309] videobuf2_common: __setup_offsets: buffer 1, plane 0 offset 0x000a9000
[  319.399552] videobuf2_common: __setup_offsets: buffer 2, plane 0 offset 0x00152000
[  319.408280] videobuf2_common: __setup_offsets: buffer 3, plane 0 offset 0x001fb000
[  319.415922] videobuf2_common: __vb2_queue_alloc: allocated 4 buffers, 1 plane(s) each
[  319.423895] videobuf2_common: vb2_mmap: buffer 0, plane 0 successfully mapped
[  319.431055] vma start=0xffff95f37000, size=692224, ret=0
[  319.431088] videobuf2_common: vb2_mmap: buffer 1, plane 0 successfully mapped
[  319.438241] vma start=0xffff95e8e000, size=692224, ret=0
[  319.438278] videobuf2_common: vb2_mmap: buffer 2, plane 0 successfully mapped
[  319.445436] vma start=0xffff95de5000, size=692224, ret=0
[  319.445463] videobuf2_common: vb2_mmap: buffer 3, plane 0 successfully mapped
[  319.452624] vma start=0xffff95d3c000, size=692224, ret=0
[  319.452639] Entered vidioc_qbuf in mx6s_capture module
[  319.452657] mx6s-csi 32e20000.csi1_bridge: mx6s_videobuf_prepare (vb=0x000000005ac9abfd) 0x00000000396c954f 0
[  319.452667] videobuf2_common: vb2_core_qbuf: qbuf of buffer 0 succeeded
[  319.459313] Entered vidioc_qbuf in mx6s_capture module
[  319.459328] mx6s-csi 32e20000.csi1_bridge: mx6s_videobuf_prepare (vb=0x0000000034804a5a) 0x0000000068683587 0
[  319.459342] videobuf2_common: vb2_core_qbuf: qbuf of buffer 1 succeeded
[  319.465983] Entered vidioc_qbuf in mx6s_capture module
[  319.465993] mx6s-csi 32e20000.csi1_bridge: mx6s_videobuf_prepare (vb=0x00000000438f8e7f) 0x0000000068acf469 0
[  319.466002] videobuf2_common: vb2_core_qbuf: qbuf of buffer 2 succeeded
[  319.472646] Entered vidioc_qbuf in mx6s_capture module
[  319.472660] mx6s-csi 32e20000.csi1_bridge: mx6s_videobuf_prepare (vb=0x000000008fe09cf0) 0x00000000d651d8a0 0
[  319.472665] videobuf2_common: vb2_core_qbuf: qbuf of buffer 3 succeeded
[  319.479313] mx6s-csi 32e20000.csi1_bridge: mx6s_videobuf_queue (vb=0x000000005ac9abfd) 0x00000000396c954f 691200
[  319.479318] mx6s-csi 32e20000.csi1_bridge: mx6s_videobuf_queue (vb=0x0000000034804a5a) 0x0000000068683587 691200
[  319.479323] mx6s-csi 32e20000.csi1_bridge: mx6s_videobuf_queue (vb=0x00000000438f8e7f) 0x0000000068acf469 691200
[  319.479327] mx6s-csi 32e20000.csi1_bridge: mx6s_videobuf_queue (vb=0x000000008fe09cf0) 0x00000000d651d8a0 691200
[  319.491273] videobuf2_common: vb2_core_streamon: successful
[  319.496954] Entered vidioc_dqbuf in mx6s_capture module
[  319.496958] videobuf2_common: vb2_core_dqbuf: Entered vb2_core_dqbuf
[  319.503340] videobuf2_common: __vb2_get_done_vb: will call __vb2_wait_for_done_vb
[  319.510874] videobuf2_common: __vb2_wait_for_done_vb: will sleep waiting for buffers
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Via gst-launch1.0:

gst-launch-1.0 -v v4l2src device="/dev/video0" ! video/x-raw,width=720,height=480,framerate=25/1,format=UYVY ! autovideosink‍

Gst-launch gives these outputs:

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data stream error.
Additional debug info:
../../../../git/libs/gst/base/gstbasesrc.c(3072): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
streaming stopped, reason not-negotiated (-4)
Execution ended after 0:00:00.000367379
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Total showed frames (0), playing for (0:00:00.000857260), fps (0.000).
Freeing pipeline ...

[  695.814388] mx6s-csi 32e20000.csi1_bridge: csi v4l2 busfreq high request.
[  695.814471] mx6s-csi 32e20000.csi1_bridge: csi v4l2 busfreq high release.
[  695.856282] mx6s-csi 32e20000.csi1_bridge: csi v4l2 busfreq high request.
[  695.857767] mx6s-csi 32e20000.csi1_bridge: Entered enum_fmt_vid_cap
[  695.857812] mx6s-csi 32e20000.csi1_bridge: Entered enum_fmt_vid_cap
[  695.857816] mx6s-csi 32e20000.csi1_bridge: No more fmt
[  695.857836] mx6s-csi 32e20000.csi1_bridge: VIDIOC_CROPCAP not implemented
[  695.863514] mx6s-csi 32e20000.csi1_bridge: csi v4l2 busfreq high release.
‍‍‍‍‍‍‍‍

I've tried both on sumo and warrior (4.19.35-imx8mm+ge6d3e3fefe4e) yocto images.


Have a nice day,

Efe

Edit:

I've checked MIPI lanes with signal analyser to check if there is anything. CLK and D1 lanes have signal.

0 Kudos
1 Solution
407 Views
efecan_icoz
Contributor III

I've found out that in NVP driver that i've mentioned only supports 4 lane mipi (device is capable of that but driver is not covering every feature i suppose).

So changing the data-lanes used by mipi-csi bridge to 4 solved the hanging in vidioc_dqbuf issue.

View solution in original post

0 Kudos
1 Reply
408 Views
efecan_icoz
Contributor III

I've found out that in NVP driver that i've mentioned only supports 4 lane mipi (device is capable of that but driver is not covering every feature i suppose).

So changing the data-lanes used by mipi-csi bridge to 4 solved the hanging in vidioc_dqbuf issue.

View solution in original post

0 Kudos