Hello all,
I have developed a camera sensor driver on Jetson Xavier NX Kernel 35.1. Sensor max9295 and max9296 are used. However, since the max9295 and max9296 drivers are probes after the camera sensor driver, the camera driver cannot operate the max9295 and max9296 functions, so the camera sensor does not become a probe. If anyone has had such a problem before, I would like your help.
Note: max9295 and max9296 driver were written before the sensor driver in the Makefile.
hello burakozbek,
I assume you have wrong device tree port bindings.
please see-also reference camera driver for using SerDes chips,
for example, $public_sources/kernel_src/hardware/nvidia/platform/t19x/common/kernel-dts/t19x-common-modules/tegra194-camera-imx390-a00.dtsi
Hello JerryChang,
Thanks for the reply.
My drivers were already working in kernel version 32.4.3. I rearranged my device tree according to the syntax of the new version, ie 35.1, as I did in the old version. I think the device tree min is correct. The only difference of 32.4.3 on 35.1 is that the max9295 and max9296 drivers were probes before the camera driver in 32.4.3 and the camera driver could easily find both devices. Here, on the contrary, since there are max9295 and max9296 probes after the camera driver, the camera driver does not have a camera probe because these two devices are probes and cannot find the camera driver for these two devices.
I am creating 2 dtsi files. These:
1-) tegra194-camera-xxxx.dtsi
2-) tegra194-camera-jakku-xxxx-dtsi
I then expect it to include file 1 in file 2. Then I include file 2 in the file named “tegra194-p3509-0000-a00.dtsi”. I read in the kernel messages that the camera driver is working but cannot find the max9295 and max9296, so it cannot be a probe. And then I see max9295 and max 9296 are probes.
I tried using IMX390 as a reference, but I saw an error like the one below in the kernel messages.
“i2c i2c-2: of_i2c: modalias error on /i2c@3180000/tca9546@70”
I don’t get this error with the device tree I created earlier. It enters the drivers correctly, but the order seems wrong. Do you have any suggestions for this?
hello burakozbek,
you may try making your camera driver as loadable kernel module, to insert it while you boot into linux kernel, then it should be probe after max9295/9296.
Hello JerryChang,
I compiled the camera driver as a module, I think it works properly, because I probed after max9295 and 9296, but this time when I try to open a stream, kernel logs are coming as below. Do you have any suggestions about these?
tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 222.942311] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 222.942523] tegra-camrtc-capture-vi tegra-capture-vi: vi5_channel_error_recover vi5_capture_dequeue
[ 222.943577] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 222.943786] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 222.944010] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 222.944178] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 0
[ 222.944769] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 228.317973] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 228.318265] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 228.318490] tegra-camrtc-capture-vi tegra-capture-vi: vi5_channel_error_recover vi5_capture_dequeue
[ 228.319539] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 228.319695] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 228.319929] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 228.320077] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 0
[ 228.320577] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 233.437948] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 233.438195] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 233.438376] tegra-camrtc-capture-vi tegra-capture-vi: vi5_channel_error_recover vi5_capture_dequeue
[ 233.439528] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 233.439678] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 233.439886] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 233.440023] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 0
[ 233.440603] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
hello burakozbek,
there’s NULL VI channel received failure, which meant invalid camera sources
is this stability issue, did you meant you sometimes able to capture camera frames?
may I also know what’s the exact steps to see such failure?
Hello JerryChang,
The camera probes successfully. I see the camera as /dev/video0, but when I try to capture the camera image with gstreamer, I get the above errors. I’m not sure what causes this problem.
hello burakozbek,
video node register to linux kernel once there’s no power-on/off failure.
please refer to developer guide, Applications Using V4L2 IOCTL Directly for using V4L2 IOCTL to verify basic functionality.
since this is SerDes chip. do you have toggle the reset signal while camera init?
besides, please monitor VI tracing logs to obtain more details.
Hello JerryChang,
How to monitor VI tracing logs?
Thanks in advance,
here’re steps to enable VI tracing logs.
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
after that, please enable camera stream and reproduce the failure.
when you seen the failure,
you can dump all VI tracing logs by… # cat /sys/kernel/debug/tracing/trace
or,
you can review dynamic tracing log with… # cat /sys/kernel/debug/tracing/trace_pipe
Hello all,
First of all, thank you for suggestions, JerryChang
I solved the problem I had. When I edited the MIPI D-PHY Deskew settings on the deserializer, my camera became working successfully. I can work with 4 cameras on 2 mipi ports now.
I hope it helps if anyone has the same problem.
Thanks.
hello burakozbek,
glad to know it works.
here’s a FYI. please refer to developer guide for SerDes Pixel Clock session.
recap as below…
Skew calibration is required if sensor or deserializer is using DPHY, and the output data rate is > 1.5Gbps.
this is new requirement for r35.1 release version. and, deskew calibration is a must if data-rate greater 1.5 Gbps.
Else the camera firmware will continue to wait for deskew signal from the sensor side. it enable pixel parser only when deskew calibration has completed.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.