I have connected Jetson xavier nx board with Serdes camera. I have 9295A serializer and 9296A de-serializer. There is only one camera-serializer module connected to the de-serializer and is using 4 lanes Mipi and connected to Jetson Xavier Nx CSI port 4 as shown in Module camera interface diagram. I am able to detect the sensor, but I am not getting any frames. Currently sensor configured for RAW12 data.
I wanted to ensure that my dtsi port mappings and bindings are correct. Please help me to check it out.
I am attaching my dtsi files and Module camera interface schematic for your reference. Please help me out.
according to the diagram.
you should revise the VI, NVCSI, and Sensor for using CSI-E, i.e. port-index = <4>;
and… please also update the serdes-csi-link accordingly,
it’s the property of GMSL link sensor/serializer connected to sensor CSI node.
furthermore, num_csi_lanes settings within tegra-camera-platform {} means the total active CSI lanes.
please also update that since it’s a 4-lane camera connected to the system.
Thanks for the input. I tried changing the port-index to 4 for VI, Channel and sensor for using CSI-E. The serdes-csi-link used is “a”. Also updated the num_csi_lanes to 4 at my end.
Still, I am not getting any frames.
Below is the dmesg log when I try to run the v4l2 camera application for above configuration.
[ 103.904814] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 103.905124] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 103.906197] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 103.906369] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=4, csi_port=4
[ 103.906588] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 103.906744] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 4 vc- 0
[ 103.907172] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
Could you please help me out to resolve this issue at my end.
As suggested changed the dst-csi-port = “e” and following changes in MAX9296.c and camera driver were done. Still getting same error and not getting any frames.
max9296.c → In function max9296_get_available_pipe(), first if condition was changed check for GMSL_CSI_PORT_E instead of GMSL_CSI_PORT_A.
static int max9296_get_available_pipe(struct device *dev,
u32 st_data_type, u32 dst_csi_port)
{
struct max9296 priv = dev_get_drvdata(dev);
int i;
for (i = 0; i < MAX9296_MAX_PIPES; i++) {
/
* TODO: Enable a pipe for multi stream configuration having
* similar stream data type. For now use st_count as a flag
* for 1 to 1 mapping in pipe and stream data type, same can
* be extended as count for many to 1 mapping. Would also need
* few more checks such as input stream id select, dst port etc.
*/
if ((priv->pipe[i].dt_type == st_data_type) &&
((dst_csi_port == GMSL_CSI_PORT_E) ?
(priv->pipe[i].dst_csi_ctrl ==
MAX9296_CSI_CTRL_0) ||
(priv->pipe[i].dst_csi_ctrl ==
MAX9296_CSI_CTRL_1) :
(priv->pipe[i].dst_csi_ctrl ==
MAX9296_CSI_CTRL_2) ||
(priv->pipe[i].dst_csi_ctrl ==
MAX9296_CSI_CTRL_3)) &&
(!priv->pipe[i].st_count))
break;
}
if (i == MAX9296_MAX_PIPES) {
dev_err(dev, “%s: all pipes are busy\n”, func);
return -ENOMEM;
}
return i;
}
camera driver → In function serdes_gmsl_board_setup() after parsing DTSI check for dst_csi_port was updated to check for port “e” and assign GMSL_CSI_PORT_E, earlier code its was corresponding to port “a”.
In function serdes_gmsl_board_setup() was updated for port E. i.e.
priv->g_ctx.dst_csi_port =
(!strcmp(str_value, “e”)) ? GMSL_CSI_PORT_E : GMSL_CSI_PORT_B;
Error Log: → Dmesg log
[ 119.143156] onsemi_serdes_driver 1-0010: onsemi_serdes_power_on: power on
[ 122.893118] onsemi_serdes_driver 1-0010: onsemi_serdes_set_mode
[ 122.893305] onsemi_serdes_driver 1-0010: start serdes streaming
[ 122.893454] max9295 1-0062: max9295_setup_streaming: stream setup is already done
[ 122.897040] max9296 1-006c: max9296_write_reg:i2c[0x6C] write success, 0x50 = 2
[ 122.897221] onsemi_serdes_driver 1-0010: start serdes streaming:: Sujit::1
[ 122.897379] onsemi_serdes_driver 1-0010: start serdes streaming:: Sujit::2
[ 125.409915] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 125.410161] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 125.419751] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 125.419974] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=4, csi_port=4
[ 125.420195] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 125.420400] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 4 vc- 0
[ 125.422513] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 125.448370] onsemi_serdes_driver 1-0010: stop serdes streaming
[ 125.449163] max9296 1-006c: max9296_write_reg:i2c[0x6C] write success, 0x50 = 0
[ 125.462620] onsemi_serdes_driver 1-0010: onsemi_serdes_power_off: power off
it looks driver side is already active for sending frames, but VI cannot recognize frame signal, such as SOF/EOF…etc
may I know which JetPack release you’re used. what’s the SerDes output date-rate?
may I know what’s your test pipeline to enable the stream?
BTW, if date-rate that’s larger then 1.5Gbps, it looks like known issue with deskew has timed out.
Sensor data-rate is 405Mbps per lane and it’s configured for 4lanes. Since per lane data-rate is not greater than 1.5Gbps, so there should not be any issue with deskew right?
Can you please elaborate what exactly “test pipeline to enable the stream” mean, so I can provide you the proper info.
all right, according to comment #8, this should be the known issue with deskew has timed out.
please refer to developer guide, Applications Using V4L2 IOCTL Directly by using V4L2 IOCTL to verify basic camera functionality.
I meant your command-lines to enable the camera stream.
as you can see in Camera Architecture Stack, it’ll going through different pipeline with different user-space plugins.
Hi Jerry Chang,
I have tested the camera without SerDes for the same 4 lane configuration using CSI Port A and its working using V4L2 application able to dump the raw frame.
With SerDes we are configuring the CSI-E, i.e. port-index = <4> we are not getting the frames. Probed at sensor and serializer using scope, we can see the signals while sensor is streaming.
Sensor data-rate is 405Mbps per lane and it’s configured for 4lanes. There should not be any deskew issue, right?
Using V4l2 application to enable the camera stream.
it’s consider total, so… it’s 405 Mbps * 4.
skew calibration is required if sensor or deserializer is using DPHY, and the output data rate is > 1.5Gbps.
I read the link GMSL Camera Framework. Its mentions 6Gbps per 4lanes, that means 1.5Gps per lane and we are within the limit. In our case its’ 405Mbps per lane. Please refer the link GmslCamera, which mentions about the limit.
We are using V4l2-ctl application (not libargus) to enable the stream. connected our camera to CSI0 without serdes and able to stream it.
As mentioned in this topic, now we are trying our camera with MAX9295 serializer and MAX9296 de-serializer. we have only this HW combination of SERDES. In our carrier board, we have mounted MAX9296 de-serializer it is connected to CSI4 port of Jeston.
we are not getting frames yet at Jetson end. I want to make our DSTI settings between de-serailizer and Jetson is proper.
can you please help me out on this.
One query regarding MAX9296. In the driver code of MAX9296 which is shown below for GMSL_CSI_PORT_E “MAX9296_LANE_CTRL2_ADDR” is selected, what is the reason for selecting this? and relationship between these two. Is always PORTE should be bind with “MAX9296_LANE_CTRL2_ADDR”?
In function max9296_setup_streaming() present in max9296.c following switch case derives CSI lane map.
/* Derive CSI lane map register */
switch(g_ctx->dst_csi_port) {
case GMSL_CSI_PORT_A:
case GMSL_CSI_PORT_D:
lane_ctrl_addr = MAX9296_LANE_CTRL1_ADDR;
break;
case GMSL_CSI_PORT_B:
case GMSL_CSI_PORT_E:
lane_ctrl_addr = MAX9296_LANE_CTRL2_ADDR;
break;
case GMSL_CSI_PORT_C:
lane_ctrl_addr = MAX9296_LANE_CTRL0_ADDR;
break;
case GMSL_CSI_PORT_F:
lane_ctrl_addr = MAX9296_LANE_CTRL3_ADDR;
break;
default:
dev_err(dev, “%s: invalid gmsl csi port!\n”, func);
err = -EINVAL;
goto ret;
};
