nvcsi on the JetsonTX2 for custom driver

By the fault the device tree sets nvcsi@150c0000 to use channel@4, in the case of implementing a driver for a different camera chip that is not supported by the common_camera library in the kernel.

Does the v4l2_mbus_config flags on for the chip configuration need to be set to V4L2_MBUS_CSI2_CHANNEL_3?

Also, in the device tree the node nvcsi@150c0000 CSI_PORT is set to <0x4> , is this port referring to the virtual channel of the chip based on the D_PHY ? documentation define it as “Defines the CSI port sensor connection” what is the csi port?
the bus_width is set to <0x2> is this the data lane support by the sensor? so if my chip only support one data lane, does it need to be <0x1> and the v4l2_mbus_config set the flag to V4L2_MBUS_CSI2_1_LANE

hello nicolas.norena,

there are descriptions for these properties settings,
please check [NVIDIA Tegra Linux Driver Package]-> [Release 28.2 Development Guide]-> [Camera Development]-> [Sensor Driver Programming Guide]
you may also check [V4L2 Sensor Driver Development Tutorial] from https://developer.nvidia.com/embedded/learn/tutorials

could you please share the failure message to have more details.
thanks

the description for the property settings csi-port and bus_width, I obtained from the [Sensor Driver Programming Guide]. It does confirm that bus_width is the data lanes it needs to support. But for the csi-port, " Defines the CSI port sensor connection. For imager devices, such as focuser or flash, this field is not required" , what does it mean by the csi port sensor connection?

I am using a different chip adv7280_m
http://www.analog.com/media/en/technical-documentation/data-sheets/adv7280a.pdf

for the error message I am getting a segmentation fault:

when the function v4l2_async_register_subdev is called and a callback function  form the ops is called with a parameter v4l2_subdev_pad_config as a null

In the [Sensor Driver Programming Guide] , a camera module is mentioned as if it is necessary to instantiate a v4l2-tegra :
/hardware/nvidia/platform/t18x/common/kernel-dts/t18x-common-modules/tegra186-camera-li-mipi-adpt-a00.dtsi
is this necessary ? I didn’t add a camera module to my dts.

example from [Sensor Driver Programming Guide]

tegra-camera-platform {
    compatible = "nvidia, tegra-camera-platform";
    modules {
        module0 {
            badge = "imx185_bottom_liimx185";
		   position = "bottom";
		   orientation = "0";
		   drivernode0 {
                pcl_id = "v4l2_sensor";
                devname = "imx185 30-001a";
                proc-device-tree = "/proc/device-tree/i2c@3180000/tca9546@70/i2c@0/imx185_a@1a";
            };        };
    };
};

hi nicolas.norena,

your device seems a video signal decoder to output MIPI signal.
I would suggest you refer to tc358840 HDMI2CSI bridge driver. you may also refer to below device tree settings
thanks

<top>/kernel_src/hardware/nvidia/platform/t18x/quill/kernel-dts/quill-modules/tegra186-camera-imx274.dtsi

The device is actually an input analog signal to the chip and the out of the chip is i2c and CSI MIPI.

I looked at the reference file you added and it does show a good example of the pipeline structure nvcsi->sensor->host1x .
In my configuration I’m removing OV5693 and replacing it with my chip.

I am still getting a segmentation fault . is there a way of testing the csi bus independently from the driver?

hello nicolas.norena,

please narrow down the issue, you may tried to configure the driver to output a test-pattern.
thanks

I did narrow down the problem to when the driver calls “v4l2_async_register_subdev()”

when it is initialized, the sub-device register function calls a call back function in the driver which passes a variable with a null, the variable should have been initialized somewhere else , see the backtrace.

Sep 08 19:23:44 tegra-ubuntu kernel: adv7280 0-0021: chip found @ 0x21 (Tegra I2C adapter)
Sep 08 19:23:44 tegra-ubuntu kernel: adv7280 0-0021: i2c_device_id name: adv7280-m 
Sep 08 19:23:44 tegra-ubuntu kernel: adv7280 0-0021: setting VPP and CSI
Sep 08 19:23:44 tegra-ubuntu kernel: adv7280 0-0021: adv7182_init function 
Sep 08 19:23:44 tegra-ubuntu kernel: adv7280 0-0021: attaching CSI device to 0x44 
Sep 08 19:23:44 tegra-ubuntu kernel: adv7280 0-0021: attaching VPP device to 0x42 
Sep 08 19:23:44 tegra-ubuntu kernel: adv7280 0-0021: state power: 0
Sep 08 19:23:44 tegra-ubuntu kernel: adv7280 0-0021: state chip info flags: 0xe
Sep 08 19:23:44 tegra-ubuntu kernel: adv7280 0-0021: client name I2C: adv7280 0-0021
Sep 08 19:23:44 tegra-ubuntu kernel: adv7280 0-0021: adv7180_init_controls function
Sep 08 19:23:44 tegra-ubuntu kernel: adv7280 0-0021: media_entity_init function
Sep 08 19:23:44 tegra-ubuntu kernel: adv7280 0-0021: adv7182_init function 
Sep 08 19:23:44 tegra-ubuntu kernel: adv7280 0-0021: irq  function
Sep 08 19:23:44 tegra-ubuntu kernel: adv7280 0-0021: v4l2 register_subdev function
Sep 08 19:23:44 tegra-ubuntu kernel: tegra-vi4 15700000.vi: subdev adv7280 0-0021 bound
Sep 08 19:23:44 tegra-ubuntu kernel: adv7280 0-0021: [adv7180_get_pad_format] v4l2_subdev_pad_config is a NULL !!
Sep 08 19:23:44 tegra-ubuntu kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Sep 08 19:23:44 tegra-ubuntu kernel: pgd = ffffffc1de30c000
Sep 08 19:23:45 tegra-ubuntu kernel: [00000000] *pgd=0000000000000000, *pud=0000000000000000
Sep 08 19:23:45 tegra-ubuntu kernel: Internal error: Oops: 96000005 [#1] PREEMPT SMP
Sep 08 19:23:45 tegra-ubuntu kernel: Modules linked in: adv7280(O+) fuse ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 xt_addrtype iptable_filter ip_tables xt_conntrack nf_nat br_netfilter overlay bcmdhd bluedroid_pm
Sep 08 19:23:45 tegra-ubuntu kernel: CPU: 3 PID: 2684 Comm: insmod Tainted: G           O    4.4.38-tegra #1
Sep 08 19:23:45 tegra-ubuntu kernel: Hardware name: deadcenter dt astro revG+ based on tegra186-tx2 (DT)
Sep 08 19:23:45 tegra-ubuntu kernel: task: ffffffc0702a0c80 ti: ffffffc1b6ae0000 task.ti: ffffffc1b6ae0000
Sep 08 19:23:45 tegra-ubuntu kernel: PC is at tegra_channel_init_subdevices+0x428/0x640
Sep 08 19:23:45 tegra-ubuntu kernel: LR is at tegra_channel_init_subdevices+0x3e8/0x640
Sep 08 19:23:45 tegra-ubuntu kernel: pc : [<ffffffc0007ae584>] lr : [<ffffffc0007ae544>] pstate: 20000045
Sep 08 19:23:45 tegra-ubuntu kernel: sp : ffffffc1b6ae38b0
Sep 08 19:23:45 tegra-ubuntu kernel: x29: ffffffc1b6ae38b0 x28: 0000000000000018 
Sep 08 19:23:45 tegra-ubuntu kernel: x27: ffffffc1c9dafc90 x26: 0000000000000000 
Sep 08 19:23:45 tegra-ubuntu kernel: x25: ffffffc1bbbfad00 x24: ffffffc1e1142000 
Sep 08 19:23:45 tegra-ubuntu kernel: x23: ffffffc1ecd884f8 x22: ffffffc1de21e800 
Sep 08 19:23:45 tegra-ubuntu kernel: x21: ffffffc1e1146000 x20: ffffffc1ecd88018 
Sep 08 19:23:45 tegra-ubuntu kernel: x19: ffffffc000c43000 x18: 0000007ffa996e78 
Sep 08 19:23:45 tegra-ubuntu kernel: x17: 0000000000000000 x16: ffffffc000b6fa60 
Sep 08 19:23:45 tegra-ubuntu kernel: x15: ffffffc000b6fa60 x14: 0000000000000001 
Sep 08 19:23:45 tegra-ubuntu kernel: x13: ffffff0000000000 x12: ffffffffffffffff 
Sep 08 19:23:45 tegra-ubuntu kernel: x11: 0000000000000001 x10: 0000000000000000 
Sep 08 19:23:45 tegra-ubuntu kernel: x9 : ffffffc1de21d000 x8 : ffffffc1c9dafc58 
Sep 08 19:23:45 tegra-ubuntu kernel: x7 : ffffffc1e11460d0 x6 : 0000000000000000 
Sep 08 19:23:45 tegra-ubuntu kernel: x5 : 8080000000000000 x4 : 0000000000000000 
Sep 08 19:23:45 tegra-ubuntu kernel: x3 : 0000000000000000 x2 : 0000000000000002 
Sep 08 19:23:45 tegra-ubuntu kernel: x1 : 0000000000000000 x0 : 0000000000000090 
Sep 08 19:23:45 tegra-ubuntu kernel: 
Sep 08 19:23:45 tegra-ubuntu kernel: Process insmod (pid: 2684, stack limit = 0xffffffc1b6ae0020)
Sep 08 19:23:45 tegra-ubuntu kernel: Call trace:
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc0007ae584>] tegra_channel_init_subdevices+0x428/0x640
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc0007af49c>] tegra_vi_graph_notify_complete+0x230/0x690
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc00079fb54>] v4l2_async_test_notify+0xfc/0x114
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc00079fd84>] v4l2_async_register_subdev+0x84/0xf8
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffbffcef8854>] adv7180_probe+0x58c/0x660 [adv7280]
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc0007772a8>] i2c_device_probe+0x184/0x23c
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc000580e78>] driver_probe_device+0xc8/0x408
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc000581254>] __driver_attach+0x9c/0xa0
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc00057eed4>] bus_for_each_dev+0x58/0x98
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc000580900>] driver_attach+0x20/0x28
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc000580470>] bus_add_driver+0x1f0/0x294
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc0005820d4>] driver_register+0x68/0x108
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc000778f8c>] i2c_register_driver+0x40/0x98
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffbffcefc020>] adv7180_driver_init+0x20/0x28 [adv7280]
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc000081c54>] do_one_initcall+0xc8/0x1c0
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc00016fd80>] do_init_module+0x64/0x1c0
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc000120f14>] load_module+0xda0/0x107c
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc00012140c>] SyS_finit_module+0x94/0xbc
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc000084ff0>] el0_svc_naked+0x24/0x28
Sep 08 19:23:45 tegra-ubuntu kernel: ---[ end trace 4ed302d22f06141f ]---

line 16, states “adv7180_get_pad_format] v4l2_subdev_pad_config is a NULL !!” , In this section is where I checked the parameter input to the function config. It is coming into the function as a NULL. Since It returns an error value , It does not configure something of the mbus and then throws a segmentation fault somewhere when trying to initialize the channel of the sub-device.

in the dts, I am referring to the documentation

38         ports {
39             #address-cells = <1>;
40             #size-cells = <0>;
41             status = "okay";
42    
43             port@0 {
44                 reg = <0>;
45                 status = "okay";
46 
47                 adv7280_out0: endpoint {
48		       status = "okay";
49                     csi-port = <0x4>;
50                     bus-width = <0x1>;
51                     remote-endpoint = <&nvcsi_out>;
52                   };
55             };

hello nicolas.norena,

please check if your struct is NULL,

<top>/kernel_src/kernel/kernel-4.4/include/media/v4l2-subdev.h

 /*
  * Used for storing subdev pad information. This structure only needs
  * to be passed to the pad op if the 'which' field of the main argument
  * is set to V4L2_SUBDEV_FORMAT_TRY. For V4L2_SUBDEV_FORMAT_ACTIVE it is
  * safe to pass NULL.
  */
 struct v4l2_subdev_pad_config {
 	struct v4l2_mbus_framefmt try_fmt;
 	struct v4l2_rect try_crop;
 	struct v4l2_rect try_compose;
 };

according to above, please have a try to modify the media bus format type.
thanks

yes the structure v4l2_subdev_pad_config is a NULL.

I forced to set the ‘which’ variable to V4L2_SUBDEV_FORMAT_ACTIVE but it still segment faults further in the initialization .
in the function tegra_channel_init_subdevices()
located in the directory drivers/media/platform/tegra/camera/vi/mc_common.h

when you say to modify the media bus format type, do you mean to change this struct?

/**
 * struct v4l2_mbus_framefmt - frame format on the media bus
 * @width:	frame width
 * @height:	frame height
 * @code:	data format code (from enum v4l2_mbus_pixelcode)
 * @field:	used interlacing type (from enum v4l2_field)
 * @colorspace:	colorspace of the data (from enum v4l2_colorspace)
 * @ycbcr_enc:	YCbCr encoding of the data (from enum v4l2_ycbcr_encoding)
 * @quantization: quantization of the data (from enum v4l2_quantization)
 * @xfer_func:  transfer function of the data (from enum v4l2_xfer_func)
 */
struct v4l2_mbus_framefmt {
	__u32			width;
	__u32			height;
	__u32			code;
	__u32			field;
	__u32			colorspace;
	__u16			ycbcr_enc;
	__u16			quantization;
	__u16			xfer_func;
	__u16			reserved[11];
};

the only parameter that looks like it would need to be supported on the v4l2 library is the variable ‘code’ which I have it set to MEDIA_BUS_FMT_UYVY8_2X8

Do you know what are the formats that are supported by Tegra V4L2?

my driver is a back ported version of this one, this is from kernel 4.19.

the kernel source I am using is from the jetpack 3.3 based on kernel 4.4.38

hello nicolas.norena,

  1. please apply the kernel patch from Topic 1038421 to fix format code conversion failure.
  2. you may also refer to our sensor driver, and VI drivers since they’re based-on kernel-4.4
<top>/kernel_src/kernel/kernel-4.4/drivers/media/i2c/

I applied the patch, updated the kernel image, and re-flashed the new image to the TX2.
It didn’t help, I am still having the same issue.

I can start debugging what is the variable that is a null in the function tegra_channel_init_subdevices , Do you have any other ideas?

I used OV5693.c as references. is there any format values that are particular to the common_camera.c

hello nicolas.norena,

  1. besides the kernel patch from Topic 1038421 to fix format code conversion failure.
    please also refer to Topic 1037809 to apply fixes for TX2 VI driver and also to add TX2 error handling mechanism.

  2. as I mentioned in comment #4, your device seems a video signal decoder to output MIPI signal. I would suggest you refer to tc358840 HDMI2CSI bridge driver. thanks

At this point, we’re getting further before we segfault.
We get to tegra_channel_sensorprops_setup, (call trace: v4l2_async_register_subdev -> v4l2_async_test_notify -> vi_graph_notify_complete -> tegra_vi_graph_build_links -> tegra_channel_init_subdevices -> tegra_channel_sensorprops_setup)

and then we segfault at the 4 memcpy calls: eg, channel.c:1054 - memcpy(ptr, &modes[i].signal_properties, size)

How are the sensor modes, num modes, and various v4l2_ctrl structures used in this function populated? Do we need to add a mode listing to our device tree? We see the example ov5693 code probe function creating a camera_common_data structure and populating the various fields, but the tc358840 driver code you pointed us towards doesn’t seem to use any camera common structures beyond pad_ops callbacks enum_frame_size and enum_frame_interval, which don’t seem to be called before we segfault anyway.

hello nicolas.norena,

you may update your sensor device tree to include these properties, you may also refer to these properties define and usage in below sources.
I’ll suggest you start with the tc358840_parse_dt() function.
thanks

<top>/kernel_src/kernel/kernel-4.4/drivers/media/i2c/tc358840.c
<top>/kernel_src/hardware/nvidia/platform/t18x/quill/kernel-dts/quill-platforms/tegra186-quill-camera-imx274.dtsi

I was able to figured out the issue with the segfault.
Using the reference driver from ov5693.c , it shows that the camera_common structure needs to be instantiated from the probe function and all the format structure members need to be mapped through the camera_common object according to my driver structure.
I saw a pose where they were having a similar issue https://devtalk.nvidia.com/default/topic/1032566/?comment=5253214

this is the snip of the code that I am referring from the OV5693:

common_data->ops		= &ov5693_common_ops;
	common_data->ctrl_handler	= &priv->ctrl_handler;
	common_data->dev		= &client->dev;
	common_data->frmfmt		= ov5693_frmfmt;
	common_data->colorfmt		= camera_common_find_datafmt(
					  OV5693_DEFAULT_DATAFMT);
	common_data->power		= &priv->power;
	common_data->ctrls		= priv->ctrls;
	common_data->priv		= (void *)priv;
	common_data->numctrls		= ARRAY_SIZE(ctrl_config_list);
	common_data->numfmts		= ARRAY_SIZE(ov5693_frmfmt);
	common_data->def_mode		= OV5693_DEFAULT_MODE;
	common_data->def_width		= OV5693_DEFAULT_WIDTH;
	common_data->def_height		= OV5693_DEFAULT_HEIGHT;
	common_data->fmt_width		= common_data->def_width;
	common_data->fmt_height		= common_data->def_height;
	common_data->def_clk_freq	= OV5693_DEFAULT_CLK_FREQ;

	priv->i2c_client = client;
	priv->s_data			= common_data;
	priv->subdev			= &common_data->subdev;
	priv->subdev->dev		= &client->dev;
	priv->s_data->dev		= &client->dev;

the reference :
[NVIDIA Tegra Linux Driver Package]-> [Release 28.2 Development Guide]-> [Camera Development]-> [Sensor Driver Programming Guide] mentions about this briefly but doesn’t explicitly cover its importance when interfacing with the nvcsi bridge driver.

After mapping the camera_common members to my driver, it would load without segfaults but the video0 was not generated.
I noticed from a pose https://devtalk.nvidia.com/default/topic/1016752/jetson-tx1/-dev-video0-can-t-create-/ that camera_common is not supported as a module. So I added my driver to built within the kernel and the video0 device node was generated at boot.

I have not tested with a video input but I can see a signal over the CSI bus when I try to cat the device node.

Also the connect tech device tree source were a good reference since they documented some of the important properties.

csi-port = <4>;     //set the CSI port #
bus-width = <2>;    //set the bus width
remote-endpoint = <&csi_in4>;     //should be CSI port# enpoint

It’s hard to find (used wget):
http://connecttech.com/ftp/dropbox/CTI-L4T-SRC-V120.tgz

the csi_port is the port from the CSI that you are physically connected to , particular pin from the board.

Hi nicolas.norena & JerryChang:
The same segmentation fault occur on our platform(TX2 + adv7280-m).
I have some confusion about the comment. As what we can see, the segmentation fault is like below:

tegra-ubuntu kernel: adv7280 0-0021: [adv7180_get_pad_format] v4l2_subdev_pad_config is a NULL !!
Sep 08 19:23:44 tegra-ubuntu kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000

23:45 tegra-ubuntu kernel: Call trace:
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc0007ae584>] tegra_channel_init_subdevices+0x428/0x640
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc0007af49c>] tegra_vi_graph_notify_complete+0x230/0x690
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc00079fb54>] v4l2_async_test_notify+0xfc/0x114
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc00079fd84>] v4l2_async_register_subdev+0x84/0xf8
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffbffcef8854>] adv7180_probe+0x58c/0x660 [adv7280]
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc0007772a8>] i2c_device_probe+0x184/0x23c
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc000580e78>] driver_probe_device+0xc8/0x408
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc000581254>] __driver_attach+0x9c/0xa0
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc00057eed4>] bus_for_each_dev+0x58/0x98
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc000580900>] driver_attach+0x20/0x28
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc000580470>] bus_add_driver+0x1f0/0x294
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc0005820d4>] driver_register+0x68/0x108
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffc000778f8c>] i2c_register_driver+0x40/0x98
Sep 08 19:23:45 tegra-ubuntu kernel: [<ffffffbffcefc020>] adv7180_driver_init+0x20/0x28 [adv7280]
Just as the backtrace said, I locate the issue code:
adv7180.c:
	format->format = *v4l2_subdev_get_try_format(sd, cfg, 0);
It is called by channel.c :
	ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, &fmt);
As the 4th parameter is NULL, so the cfg is set to be NULL, that is why the segmentaion fault occur.
But as we can see in the above comments , why you modify camera_common object ? I searched the total code in adv7180.c, but there are no related code about camera_common, so I want to know why???

Waiting for you reply sincerely.

		                                                                     Thanks.

I had the same issue, I modified the function in my driver that handles the get_pad_format() and set_pad_format() to check for the NULL .

*v4l2_subdev_get_try_format(sd, cfg, 0); can’t be used with cfg = NULL.

Glad to get your reply.
I try to solve this issue with below:

  1. Initialize a global variable: static struct v4l2_subdev_pad_config *cfg_ad = NULL;
  2. Instantiat it when probe;
    After that, I find the CSI data is null.
    And I got 3 kinds of errors:
  3. v4l2-compliance -d /dev/video0
v4l2-compliance SHA: not available, 64 bits

Compliance test for device /dev/video0:

Driver Info:
	Driver name      : tegra-video
	Card type        : vi-output, adv7180 2-0021
	Bus info         : platform:15700000.vi:2
	Driver version   : 4.4.38
	Capabilities     : 0x84200001
		Video Capture
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps      : 0x04200001
		Video Capture
		Streaming
		Extended Pix Format

Required ioctls:
	test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
	test second /dev/video0 open: OK
	test VIDIOC_QUERYCAP: OK
	test VIDIOC_G/S_PRIORITY: OK
	test for unlimited opens: OK

Debug ioctls:
	test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
	test VIDIOC_LOG_STATUS: OK

Input ioctls:
	test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
	test VIDIOC_ENUMAUDIO: OK (Not Supported)
	test VIDIOC_G/S/ENUMINPUT: OK
	test VIDIOC_G/S_AUDIO: OK (Not Supported)
	Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
	test VIDIOC_G/S_MODULATOR: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_ENUMAUDOUT: OK (Not Supported)
	test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDOUT: OK (Not Supported)
	Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
	test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
	test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
	test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
	test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls (Input 0):
	test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
	test VIDIOC_QUERYCTRL: OK
	test VIDIOC_G/S_CTRL: OK
		fail: v4l2-test-controls.cpp(794): doioctl(node, VIDIOC_G_EXT_CTRLS, &ctrls)
	test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
	test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
	test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
	Standard Controls: 6 Private Controls: 11

Format ioctls (Input 0):
	test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
	test VIDIOC_G/S_PARM: OK (Not Supported)
	test VIDIOC_G_FBUF: OK (Not Supported)
		fail: v4l2-test-formats.cpp(330): !colorspace
		fail: v4l2-test-formats.cpp(438): testColorspace(pix.pixelformat, pix.colorspace, pix.ycbcr_enc, pix.quantization)
	test VIDIOC_G_FMT: FAIL
	test VIDIOC_TRY_FMT: OK (Not Supported)
	test VIDIOC_S_FMT: OK (Not Supported)
	test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
	test Cropping: OK (Not Supported)
	test Composing: OK (Not Supported)
	test Scaling: OK

Codec ioctls (Input 0):
	test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
	test VIDIOC_G_ENC_INDEX: OK (Not Supported)
	test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls (Input 0):
	test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
		fail: v4l2-test-buffers.cpp(546): VIDIOC_EXPBUF is supported, but the V4L2_MEMORY_MMAP support is missing, probably due to earlier failing format tests.
	test VIDIOC_EXPBUF: OK (Not Supported)

Total: 43, Succeeded: 41, Failed: 2, Warnings: 0
  1. In the kernel log, I found a warning and error:
    tegra-vi4 15700000.vi: WAR:Calculation not precise.Ignore BW request failure

tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11

  1. When checking the trace, the error shows:
# tracer: nop
#
# entries-in-buffer/entries-written: 61/61   #P:4
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
     kworker/0:0-3175  [000] ...1  5701.649781: rtos_queue_peek_from_isr_failed: tstamp:178525044010 queue:0x0b4a3c58
     kworker/0:0-3175  [000] ...1  5701.805649: rtos_queue_peek_from_isr_failed: tstamp:178530044947 queue:0x0b4a3c58
     kworker/0:0-3175  [000] ...1  5702.013613: rtos_queue_peek_from_isr_failed: tstamp:178535045335 queue:0x0b4a3c58
     kworker/0:0-3175  [000] ...1  5702.169618: rtos_queue_peek_from_isr_failed: tstamp:178540045864 queue:0x0b4a3c58
     kworker/0:0-3175  [000] ...1  5702.329597: rtos_queue_peek_from_isr_failed: tstamp:178545046060 queue:0x0b4a3c58
     kworker/0:0-3175  [000] ...1  5702.485608: rtos_queue_peek_from_isr_failed: tstamp:178550046861 queue:0x0b4a3c58
     kworker/0:0-3175  [000] ...1  5702.641599: rtos_queue_peek_from_isr_failed: tstamp:178555047361 queue:0x0b4a3c58
     kworker/0:0-3175  [000] ...1  5702.797624: rtos_queue_peek_from_isr_failed: tstamp:178560047872 queue:0x0b4a3c58
     kworker/0:0-3175  [000] ...1  5702.953670: rtos_queue_peek_from_isr_failed: tstamp:178565048396 queue:0x0b4a3c58
     kworker/0:0-3175  [000] ...1  5703.109657: rtos_queue_peek_from_isr_failed: tstamp:178570048883 queue:0x0b4a3c58

So do you why?
And I want to know is it possible that can you send me the related source code? such as the dts and adv7180.c ?

Thanks very much.

Status update:
We double-checked the CSI signal, and found that the signal output successfully, but the signal voltage is a little low, CSI data voltage is 800mV, CSI clk voltage is 80mV, so we want to know is that why we can not get the video?
CSI DATA:
file:///home/nvidia/Downloads/webwxgetmsgimg.jpg
CSI CLK:
file:///home/nvidia/Downloads/webwxgetmsgimg%20(1).jpg

Thanks very much.