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.
已解决! 转到解答。
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.
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.