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
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 [url]https://developer.nvidia.com/embedded/learn/tutorials[/url]
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?
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.
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
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?
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.
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.
<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?
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.
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.
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
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:
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
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:
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.
Glad to get your reply.
I try to solve this issue with below:
Initialize a global variable: static struct v4l2_subdev_pad_config *cfg_ad = NULL;
Instantiat it when probe;
After that, I find the CSI data is null.
And I got 3 kinds of errors:
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
In the kernel log, I found a warning and error:
tegra-vi4 15700000.vi: WAR:Calculation not precise.Ignore BW request failure
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
