I ported a camera driver from the previous Jetpack version 4.6.2 to 5.0.2. After adjusting the device tree I now face the problem that the tegra-capture-vi reports a timeout. No camera images are received. I checked data transmission with an oscilloscope. I am using a IMX296 with 1 lane so the data0 Lane shows data transmission.
I do get following error messages:
[ 2663.613160] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 5000 ms
[ 2663.613461] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 2663.614925] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 2663.615171] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=2, csi_port=2
[ 2663.615436] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 2663.615656] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 2 vc- 0
[ 2663.616284] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
Are the some additional things to do when porting a camera driver to Jetpack 5.0.2?
Check the pix_clk_hz in device tree to make sure the output data rate > 1.5Gbps
After that get the trace log to analysis.
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)
What entry in the trace gives the hint that the received data are not valid? I checked the data0 lane with a oscilloscope and the sensor is sending data. But my oscilloscope isn’t capable to decode the signal itself.
According to the D-PHY spec the LP00 has to be between 40 ns + 4UI and 85 ns + 6UI. In my case 1UI is 1 / 742.5 MHz = 1.34 ns. This leads to a valid LP00 range of 45.38 ns - 93.08 ns. The measured LP00 time duration on my signal is approximately 65 ns. So , I assume this is not causing the problem.