IntelRealSense / realsense_mipi_platform_driver

Intel® RealSense™ camera driver for GMSL* interface
GNU General Public License v2.0
15 stars 14 forks source link

Draft - supporting D457 R8L8 with Y8I format #61

Closed shikundi closed 2 years ago

shikundi commented 2 years ago

Signed-off-by: Shikun, Ding shikun.ding@intel.com

shikundi commented 2 years ago

Y8I description could be listed when enumerating all formats on /dev/video4

$ v4l2-ctl -d /dev/video4 --list-formats
ioctl: VIDIOC_ENUM_FMT
        Index       : 0
        Type        : Video Capture
        Pixel Format: 'GREY'
        Name        : 8-bit Greyscale

        Index       : 1
        Type        : Video Capture
        Pixel Format: 'Y8I '
        Name        : 16-bit Interleaved L/R

But to stream on /dev/video4 using v4l2-ctrl or rs_viewer, got no reply from camera processor message $ v4l2-ctl -d /dev/video4 --set-fmt-video=pixelformat=1 --stream-mmap=3 --stream-count=5 Or Used the rs_viewer application compiled from xzhangxa/perc_hw_ds5u_android-jetson_tx2 at gui_fix (github.com) to test:

image

image

shikundi commented 2 years ago

Update: I tried to find the root cause of y8i not work. And currently, I found that From the log comparison between y8 and y8i: image

These flags indicates that Y8 's status is SUCCESS while Y8I with error image

I really don't know what's the mean of __CAPTURE_STATUS_FALCON_ERROR__.

Continue debug the issue by turning the trace mechanism. Found that when streaming with Y8I format, many errors called __CHANSELNOMATCH are output and its data is 0x00000649

image

Referred to https://elinux.org/Jetson/l4t/Camera_BringUp, got that image

So the 0x00000649 is turned to be 0b110010 0100 1
bit 0: 1 --->not match
bit 1-4 : 0100 ---> LS
bit 5-10:110010  --> __NvCsiDataType_User_3__

The strange thing is I have already set the data type to 0x32 (50 in decimal) and the log from Y8I also verified my correct setting on data type: image

and my hardcode used for debug: image

Have no idea why got a __CHANSELNOMATCH......................

xzhangxa commented 2 years ago

Please combine the two commits into one. The code is not updated as we synced?

shikundi commented 2 years ago

Please combine the two commits into one. The code is not updated as we synced?

Squash them later after full test.

shikundi commented 2 years ago

Update: These are the previous setting for y8i in vi driver d4xx and SerDes script:

video_formats: TEGRA_IMAGE_DT_USER_3 0x32
D4xx: data type register 0x4080 ----> 0x32
          override register 0x409c  -----> 0x32
SerDes script: sudo i2cset -f -y 2 0x40 0x03 0x7219 w # Pipe Z pulls Y8I (DT 0x32)

Got these errors from dmesg and RTCPU trace: Trace: image

dmesg: corr_err: descr->status.status: 14 discarding frame 0 , flags: 6, err_data 131072

It shows that the datatype and line number are all mismatched.


Currently , changing the setting

video_formats: TEGRA_IMAGE_DT_YUV422_8 0x1e
D4xx: data type register 0x4080 ----> 0x32
          override register 0x409c ----> 0x1e
SerDes script: sudo i2cset -f -y 2 0x40 0x03 0x5E19 w # Pipe Z pulls Y8I (DT 0x1E)

these changes are all push to this PR.

Trace: image

the Errors that CHANSEL_FAULT and CHANSEL_NOMATCH disappeared. Only the CHANSEL_SHORT_FRAME lasts.

But the __CAPTURE_STATUS_FALCON_ERROR__ (14 )in dmesg still exists.

I post my problems to a topic in Nvidia forum , and got a reply: https://forums.developer.nvidia.com/t/jetson-agx-xavier-capture-error-from-my-camera/205478/12 image

shikundi commented 2 years ago

@ev-mp Please help close this PR since the Y8I enabled in #78 pushed by @xzhangxa