Porting camera driver from L4T32.7.3 to L4T35.3.1

We have working V4l driver under L4T32.7.3.
I copied driver files in drivers/media/i2c, made one modification:
#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 4, 0)
.use_single_rw = true,
#else
.use_single_read = true,
.use_single_write = true,
#endif
and was able to rebuild kernel image.
I copied device tree files in “platform/t19x/jakku/kernel-dts/common”, added
" tegra-capture-vi {"
according to imx477 device tree file and was able to rebuild device tree and have “/dev/video0” and /dev/media0" created.
When I run the same v4l2-ctl command to capture frames, I got errors:
[ 129.247570] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 129.247838] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 129.248700] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 129.248890] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 129.249118] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 129.249290] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 0
[ 129.249821] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 131.807664] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 131.808004] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 131.808678] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 131.808866] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 131.809189] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 131.809368] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 0

I have never seen such errors under L4T32.7.3.
What changes are needed to port camera drivers from L4T32.7.3 to L4T35.3.1?
Thanks in advance for helps

Please confirm the data output rate > 1.5Gbps for 35.x release.

Skew calibration is required if sensor or deserializer is using DPHY, and the output data rate is > 1.5Gbps.
An initiation deskew signal should be sent by sensor or deserializer to perform the skew calibration. If the deskew signals is not sent, the receiver will stall, and the capture will time out.
You can calculate the output data rate with the following equation:

Output data rate = (sensor or deserializer pixel clock in hertz) * (bits per pixel) / (number of CSI lanes)

I tested modes with 800Mbps and 400Mbps MIPI D-PHY lane rates. Both rates are unstable with V4l2-ctl, i.e., when repeatedly running v4l2-ctl, it works sometime and does not work more times. The command is:
v4l2-ctl --set-fmt-video=width=4096,height=3072,pixelformat=RG10 --stream-mmap --set-ctrl=sensor_mode=2 --stream-count=100 -d /dev/video0 --verbose

When it worked, all 100 frames were captured with correct frame rate.
cap dqbuf: 0 seq: 92 bytesused: 25165824 ts: 248.147599 delta: 92.995 ms fps: 10.75 (ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq: 93 bytesused: 25165824 ts: 248.240594 delta: 92.995 ms fps: 10.75 (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq: 94 bytesused: 25165824 ts: 248.333590 delta: 92.996 ms fps: 10.75 (ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq: 95 bytesused: 25165824 ts: 248.426585 delta: 92.995 ms fps: 10.75 (ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq: 96 bytesused: 25165824 ts: 248.519580 delta: 92.995 ms fps: 10.75 (ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq: 97 bytesused: 25165824 ts: 248.612576 delta: 92.996 ms fps: 10.75 (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq: 98 bytesused: 25165824 ts: 248.705571 delta: 92.995 ms fps: 10.75 (ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq: 99 bytesused: 25165824 ts: 248.798566 delta: 92.995 ms fps: 10.75 (ts-monotonic, ts-src-eof)

when it did not work, no frame was captured:
cap dqbuf: 0 seq: 0 bytesused: 25165824 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq: 1 bytesused: 25165824 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq: 2 bytesused: 25165824 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq: 3 bytesused: 25165824 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq: 0 bytesused: 25165824 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq: 0 bytesused: 25165824 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq: 1 bytesused: 25165824 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq: 2 bytesused: 25165824 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq: 3 bytesused: 25165824 ts: 0.000000 (error, ts-monotonic, ts-src-eof)

3 out 4 times it failed. We never had the same issues with L4T32.7.3 using the same hardware.
Is it possible to use L4T32.7.3 kernel with L4T35.3.1 rootfs?
Thanks

Could you boost the clocks to verify.

sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee  /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate

This helped to get higher frame rates. Is there a way to set maximum clock frequencies automatically at power up without running the script?
Thanks!

You can modify the tegra_camera_platform.c for it.

Thanks

Which function in “tegra_camera_platform.c” should I modify?
I could not find which function call to set emc clock rate.
Thanks

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.