Mipi problem

Hello,i use lt6911uxe in JetsonOrinNX16GB,and bsp is 35.5.0.
I configured the device tree and the driver, and the system generated /dev/video0 as normal, but I ran into problems when I tried to use the device.

cat /dev/video0
[ 1564.887992] bwmgr API not supported
[ 1567.623475] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 1.636248] ra-rtc-care-vi tegra-cape-vi: errc: attempting to rt tcaphannel
[ 1567.66130(NULL device *): vi_cure_contrmessage: NULL Vhannel received
[ 1.679970] t19vcs3e40.h1x:15a00000: csstreamose: Er in closingread=0, cpor
[ 1.70490(NUdevice *): vi_capt_contrmessage: NULL VI chan received
[ 1.72tegra-camrtc-capture-vi tegra-capturi: _rec: cessfully re the capture channel
[ 1.774921] tegcam-captuvi ra-capture-vi: uncorrr: requesimed out er 2500 ms
[ 1925.797383] tegra-rtc-care-vi tegcapturi: errc: attting tesehe ture c[ 19250510] LL ice: vi_capture_cool_message: NULL VI channel received
[ 1925.84t19vcsi 10000.h1x:nvcsi@15a000 csi5_streamose: Error in cing stread=0, csi_t=0[ 1.86745(NULL device *)apt_control_e: NULI channel reved
[ 1.18tegra-cam-captuvi tegcape-vi: _rec: successfullyset the cureannel

I refer to the article here for testing,also a failure.
Bwmgr API not supported error on Orin AGX - Jetson & Embedded Systems / Jetson AGX Orin - NVIDIA Developer Forums

[ 2974.153174] tegra194-vi5 13e40000.host1x:vi0@15c00000: capture control message timed out
[ 2974.161581] tegra-camrtc-capture-vi tegra-capture-vi: vi capture setup failed
[ 2975.180973] tegra194-vi5 13e40000.host1x:vi0@15c00000: capture control message timed out
[ 2975.189320] tegra194-vi5 13e40000.host1x:vi0@15c00000: csi_stream_release: failed to disable nvcsi tpg on stream 0 virtual channel 0

please help me,thank you

hello Towe_Roll,

it’s reporting NULL Vhannel received, which usually means there’s no signaling on the CSI channel.
is it possible to probe the signaling by oscilloscope? please check there’re frames packets on the CSI channel.

hello, this is the measurement

my device-tree
tegra234-p3767-0000-a0-lt6911uxe.txt (7.8 KB)

hello Towe_Roll,

it looks it’s configured to 16-bit YUYV.
may I know what’s your test pipeline, you must use v4l2src.
for example,
$ gst-launch-1.0 v4l2src device=/dev/videoX ! video/x-raw,width=1920,height=1080,format=YUY2,framerate=30/1 ! xvimagesink

v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=YUYV --stream-mmap=4 --stream-count=1 --stream-to=~/cap.raw --stream-skip=2

Speaking of which, I would like to ask, my device is actually Mipi output format is YUV422 8bit, but I set csi_pixel_bit_depth and dynamic_pixel_bit_depth to 8 when loading the driver error, Why is that? Is it my configuration

hello , JerryChang , Do I want to know how to switch to other modes when my system starts (mode0 mode1 mode2)

hello Towe_Roll,

(1) device tree settings must be same as your hardware capability, may I also know what the error for loading the drivers?
please see-also VI driver, is it reported not supported format failure?
i.e. $public_sources/kernel_src/kernel/nvidia/drivers/media/platform/tegra/camera/sensor_common.c
here’s conversion from device tree properties as v4l formats,
for instance, mode_type + pixel_phase + csi_pixel_bit_depth .

static int extract_pixel_format(
        const char *pixel_t, u32 *format)
{
...
        else if (strncmp(pixel_t, "yuv_yuyv16", size) == 0)
                *format = V4L2_PIX_FMT_YUYV;
        else if (strncmp(pixel_t, "yuv_yvyu16", size) == 0)
                *format = V4L2_PIX_FMT_YVYU;
        else if (strncmp(pixel_t, "yuv_uyvy16", size) == 0)
                *format = V4L2_PIX_FMT_UYVY;
        else if (strncmp(pixel_t, "yuv_vyuy16", size) == 0)
                *format = V4L2_PIX_FMT_VYUY;

(2) you may enable device tree property, by setting use_sensor_mode_id as true,
then, you could enable v4l2 command-line to toggle mode selection, note, the resolution settings should be the same as the sensor mode.
for instance,
$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1280,height=720,pixelformat=RG10 --set-ctrl bypass_mode=0 --set-ctrl sensor_mode=4 --stream-mmap --stream-count=100

(3)

BTW, YUYV is defined as YUY2 in v4l2src.

(4) it’s reporting timestamp problems according to below…

please check V4L2 IOCTL with --list-formats-ext options to dump the support format types.
please test with other mode tables, and also adding video converter for confirmation.
for exmaple,
$ gst-launch-1.0 v4l2src device=/dev/video2 ! 'video/x-raw,width=1920,height=1080,format=YUY2' ! videoconvert ! 'video/x-raw,format=I420' ! fpsdisplaysink text-overlay=0 video-sink=fakesink sync=0 -v

hello JerryChang,
i use csi0 and csi1 for 4lane, so tegra_sinterface is serial_a?

hello JerryChang,
my phyclk is 714MHz,and is 4lane yuv422, so pix_clk_hz = “178500000” right?

image

hello Towe_Roll,

yes, that’s correct. please also aware there’s polarity swap configuration for using CSI-A/B.
you should also have lane_polarity = "6"; in your device tree settings.

you may see-also Sensor Pixel Clock section,
it’s 148500000 if using the frame size and frame rate for calculation. please also give it a try.

hello JerryChang,
Should I use serdes_pix_clk_hz? I use lt6911uxe, its hdmi to mipicsi2.

you should uses pix_clk_hz as I don’t think you’re having Jetson Virtual Channel with GMSL Camera Framework.

hello JerryChang
How can I see more debugging information about mipicsi

hello Towe_Roll,

you may follow below steps to enable VI tracing logs.
it enables the logs printed by RCE. (Real-time Camera Engine)

echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 30720 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/tegra_rtcpu/enable
echo 1 > /sys/kernel/debug/tracing/events/freertos/enable
echo 2 > /sys/kernel/debug/camrtc/log-level
echo > /sys/kernel/debug/tracing/trace
cat /sys/kernel/debug/tracing/trace

hello JerryChange,

this my log.

gst-launch-1.0 v4l2src device=/dev/video0 num-buffers=1 ! vi deo/x-raw,width=1920,height=1080,format=YUY2,framerate=60/1 ! jpegenc ! filesink location=1.jpg

dmesg.log (64.7 KB)


trace.log (358.7 KB)

this is my device-tree
tegra234-p3767-0000-a0-lt6911uxe.txt (7.7 KB)

Please give me some ideas,thank you.

hello Towe_Roll,

there shows PHY interrupts, the error code 0x8 means LP sequence error has detected on data-lane.
normally, it should follow by LP11->LP01->LP00->LP11 sequence. it’s more like a hardware issue.

Hello JerryChang,
I don’t quite understand what this means, LP11->LP01->LP00->LP11 sequence, what does this stand for and how can I see it from this trace, thank you

Hello JerryChang,
We checked the hardware and found that the LANE_P and LANE_N of the hardware were connected in reverse. I would like to ask if there is a way for them to exchange on the software. If not, we can only redesign the hardware, thank you