Device Tree Issue with LT6911UXC

Hi All,

I have a board built up with all the support circuitry with a Lontium LT6911UXC chip and now that Lontium have provided me with new firmware I’m getting MIPI data out when I connect a video source. The video is sourced from a Raspberry Pi and currently set to 1920x1080p50 and the next test will be with 4k if I ever get this working.

The kernel is loading the driver and says it can see the device but when I run the following command I get an error which is listed under the comman below:

Test Command
v4l2-ctl --set-fmt-video=width=1920,height=1080 --stream-mmap --stream-count=100 -d /dev/video0 --stream-to=test.raw

Error output
[ 474.338086] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 474.338467] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 474.340799] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 474.341056] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=4, csi_port=4
[ 474.341273] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 474.341472] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 4 vc- 0
[ 474.341994] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel

Can anyone point me in the right direction as to what this error is and how to correct it please? I’m stuck on this point and can’t seem to make headway so I’d be ever so grateful if someone could assist.

Further Information; This is with a carrier from VVDN, the MIPI data is RGB888 and 4 lanes are in use. I’m connected via i2c0 device node which is i2c bus8 @ 3160000.

I think my device tree file is wrong and is shown below:
/*

  • Copyright (c) 2017-2022, NVIDIA CORPORATION. All rights reserved.
  • This program is free software; you can redistribute it and/or modify
  • it under the terms of the GNU General Public License as published by
  • the Free Software Foundation; either version 2 of the License, or
  • (at your option) any later version.
  • This program is distributed in the hope that it will be useful, but WITHOUT
  • ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  • FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
  • more details.
  • You should have received a copy of the GNU General Public License
  • along with this program. If not, see http://www.gnu.org/licenses/.
    */
    define CAM3_PWDN TEGRA194_MAIN_GPIO(Q, 6)

/ {
tegra-capture-vi {
num-channels = <1>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
e2832_vi_in0: endpoint {
port-index = <4>;
bus-width = <8>;
remote-endpoint = <&e2832_csi_out0>;
};
};
};
};

host1x@13e00000 {
	nvcsi@15a00000 {
		num-channels = <1>;
		#address-cells = <1>;
		#size-cells = <0>;
		channel@0 {
			reg = <0>;
			ports {
				#address-cells = <1>;
				#size-cells = <0>;
				port@0 {
					reg = <0>;
					e2832_csi_in0: endpoint@0 {
						port-index = <4>;
						bus-width = <8>;
						remote-endpoint = <&e2832_out0>;
					};
				};
				port@1 {
					reg = <1>;
					e2832_csi_out0: endpoint@1 {
						remote-endpoint = <&e2832_vi_in0>;
					};
				};
			};
		};
	};
};

i2c@31e0000 {
	e2832@2b {
		compatible = "nvidia,lt6911uxc";
		/* I2C device address */
		reg = <0x2b>;

		/* V4L2 device node location */
		devnode = "video0";

		reset-gpios = <&tegra_main_gpio CAM3_PWDN GPIO_ACTIVE_HIGH>;

		/* Physical dimensions of sensor */
		physical_w = "3.674";
		physical_h = "2.738";

		sensor_model = "e2832";

		/* Define any required hw resources needed by driver */
		/* ie. clocks, io pins, power sources */
		avdd-reg = "vana";
		iovdd-reg = "vif";
		dvdd-reg = "vdig";

		/* Defines number of frames to be dropped by driver internally after applying */
		/* sensor crop settings. Some sensors send corrupt frames after applying */
		/* crop co-ordinates */
		/*post_crop_frame_drop = "0";*/

		/**
		* ==== Modes ====
		* A modeX node is required to support v4l2 driver
		* implementation with NVIDIA camera software stack
		*
		* == Signal properties ==
		*
		* phy_mode = "";
		* PHY mode used by the MIPI lanes for this device
		*
		* tegra_sinterface = "";
		* CSI Serial interface connected to tegra
		* Incase of virtual HW devices, use virtual
		* For SW emulated devices, use host
		*
		* pix_clk_hz = "";
		* Sensor pixel clock used for calculations like exposure and framerate
		*
		* readout_orientation = "0";
		* Based on camera module orientation.
		* Only change readout_orientation if you specifically
		* Program a different readout order for this mode
		*
		* == Image format Properties ==
		*
		* active_w = "";
		* Pixel active region width
		*
		* active_h = "";
		* Pixel active region height
		*
		* pixel_t = "";
		* The sensor readout pixel pattern
		*
		* line_length = "";
		* Pixel line length (width) for sensor mode.
		*
		* == Source Control Settings ==
		*
		* Gain factor used to convert fixed point integer to float
		* Gain range [min_gain/gain_factor, max_gain/gain_factor]
		* Gain step [step_gain/gain_factor is the smallest step that can be configured]
		* Default gain [Default gain to be initialized for the control.
                                 *     use min_gain_val as default for optimal results]
		* Framerate factor used to convert fixed point integer to float
		* Framerate range [min_framerate/framerate_factor, max_framerate/framerate_factor]
		* Framerate step [step_framerate/framerate_factor is the smallest step that can be configured]
		* Default Framerate [Default framerate to be initialized for the control.
                                 *     use max_framerate to get required performance]
		* Exposure factor used to convert fixed point integer to float
		* For convenience use 1 sec = 1000000us as conversion factor
		* Exposure range [min_exp_time/exposure_factor, max_exp_time/exposure_factor]
		* Exposure step [step_exp_time/exposure_factor is the smallest step that can be configured]
		* Default Exposure Time [Default exposure to be initialized for the control.
                                 *     Set default exposure based on the default_framerate for optimal exposure settings]
		* For convenience use 1 sec = 1000000us as conversion factor
		*
		* gain_factor = ""; (integer factor used for floating to fixed point conversion)
		* min_gain_val = ""; (ceil to integer)
		* max_gain_val = ""; (ceil to integer)
		* step_gain_val = ""; (ceil to integer)
		* default_gain = ""; (ceil to integer)
		* Gain limits for mode
		*
		* exposure_factor = ""; (integer factor used for floating to fixed point conversion)
		* min_exp_time = ""; (ceil to integer)
		* max_exp_time = ""; (ceil to integer)
		* step_exp_time = ""; (ceil to integer)
		* default_exp_time = ""; (ceil to integer)
		* Exposure Time limits for mode (sec)
		*
		* framerate_factor = ""; (integer factor used for floating to fixed point conversion)
		* min_framerate = ""; (ceil to integer)
		* max_framerate = ""; (ceil to integer)
		* step_framerate = ""; (ceil to integer)
		* default_framerate = ""; (ceil to integer)
		* Framerate limits for mode (fps)
		*
		* embedded_metadata_height = "";
		* Sensor embedded metadata height in units of rows.
		* If sensor does not support embedded metadata value should be 0.

		* num_of_exposure = "";
		* Digital overlap(Dol) frames
		*
		* num_of_ignored_lines = "";
		* Used for cropping, eg. OB lines + Ignored area of effective pixel lines
		*
		* num_of_lines_offset_0 = "";
		* Used for cropping, vertical blanking in front of short exposure data
		* If more Dol frames are used, it can be extended, eg. num_of_lines_offset_1
		*
		* num_of_ignored_pixels = "";
		* Used for cropping, The length of line info(pixels)
		*
		* num_of_left_margin_pixels = "";
		* Used for cropping, the size of the left edge margin before
		* the active pixel area (after ignored pixels)
		*
		* num_of_right_margin_pixels = "";
		* Used for cropping, the size of the right edge margin after
		* the active pixel area
		*
		*/

		mode0 { // E2832_1920x1080_60Fps
			mclk_khz = "24000";
			num_lanes = "4";
			tegra_sinterface = "serial_e";
			phy_mode = "DPHY";
			discontinuous_clk = "yes";
			dpcm_enable = "false";
			cil_settletime = "0";

			active_w = "1920";
			active_h = "1080";
			mode_type = "rgb";
			pixel_phase = "rgb888";
			csi_pixel_bit_depth = "24";
			readout_orientation = "0";
			line_length = "1920";
			inherent_gain = "1";
			mclk_multiplier = "24";
			pix_clk_hz = "220000000";

			gain_factor = "16";
			framerate_factor = "1000000";
			exposure_factor = "1000000";
			min_gain_val = "16"; /* 1.00x */
			max_gain_val = "170"; /* 10.66x */
			step_gain_val = "1";
			default_gain = "16"; /* 1.00x */
			min_hdr_ratio = "1";
			max_hdr_ratio = "1";
			min_framerate = "2000000"; /* 2.0 fps */
			max_framerate = "60000000"; /* 60.0 fps */
			step_framerate = "1";
			default_framerate = "60000000"; /* 60.0 fps */
			min_exp_time = "13"; /* us */
			max_exp_time = "683709"; /* us */
			step_exp_time = "1";
			default_exp_time = "16667"; /* us  */
		};
		mode1 { // E2832_3840x2160
			mclk_khz = "24000";
			num_lanes = "8";
			tegra_sinterface = "serial_e";
			phy_mode = "DPHY";
			discontinuous_clk = "yes";
			dpcm_enable = "false";
			cil_settletime = "0";

			active_w = "3840";
			active_h = "2160";
			mode_type = "rgb";
			pixel_phase = "rgb888";
			csi_pixel_bit_depth = "24";
			readout_orientation = "0";
			line_length = "3840";
			inherent_gain = "1";
			mclk_multiplier = "24";
			pix_clk_hz = "500000000";

			gain_factor = "16";
			framerate_factor = "1000000";
			exposure_factor = "1000000";
			min_gain_val = "16"; /* 1.00x */
			max_gain_val = "170"; /* 10.66x */
			step_gain_val = "1";
			default_gain = "16"; /* 1.00x */
			min_hdr_ratio = "1";
			max_hdr_ratio = "1";
			min_framerate = "2000000"; /* 2.0 fps */
			max_framerate = "60000000"; /* 60.0 fps */
			step_framerate = "1";
			default_framerate = "60000000"; /* 60.0 fps */
			min_exp_time = "13"; /* us */
			max_exp_time = "683709"; /* us */
			step_exp_time = "1";
			default_exp_time = "16667"; /* us  */
		};
		mode2 { // E2832_1280x720_60Fps
			mclk_khz = "24000";
			num_lanes = "4";
			tegra_sinterface = "serial_e";
			phy_mode = "DPHY";
			discontinuous_clk = "yes";
			dpcm_enable = "false";
			cil_settletime = "0";

			active_w = "1280";
			active_h = "720";
			mode_type = "rgb";
			pixel_phase = "rgb888";
			csi_pixel_bit_depth = "24";
			readout_orientation = "0";
			line_length = "1280";
			inherent_gain = "1";
			mclk_multiplier = "24";
			pix_clk_hz = "220000000";

			gain_factor = "16";
			framerate_factor = "1000000";
			exposure_factor = "1000000";
			min_gain_val = "16"; /* 1.00x */
			max_gain_val = "170"; /* 10.66x */
			step_gain_val = "1";
			default_gain = "16"; /* 1.00x */
			min_hdr_ratio = "1";
			max_hdr_ratio = "1";
			min_framerate = "2000000"; /* 2.0 fps */
			max_framerate = "60000000"; /* 60.0 fps */
			step_framerate = "1";
			default_framerate = "60000000"; /* 60.0 fps */
			min_exp_time = "13"; /* us */
			max_exp_time = "683709"; /* us */
			step_exp_time = "1";
			default_exp_time = "16667"; /* us  */
		};

		ports {
			#address-cells = <1>;
			#size-cells = <0>;
			port@0 {
				reg = <0>;
				e2832_out0: endpoint {
					port-index = <4>;
					bus-width = <8>;
					remote-endpoint = <&e2832_csi_in0>;
				};
			};
		};
	};
};

};

/ {

tegra-camera-platform {
	compatible = "nvidia, tegra-camera-platform";
	/**
	* Physical settings to calculate max ISO BW
	*
	* num_csi_lanes = <>;
	* Total number of CSI lanes when all cameras are active
	*
	* max_lane_speed = <>;
	* Max lane speed in Kbit/s
	*
	* min_bits_per_pixel = <>;
	* Min bits per pixel
	*
	* vi_peak_byte_per_pixel = <>;
	* Max byte per pixel for the VI ISO case
	*
	* vi_bw_margin_pct = <>;
	* Vi bandwidth margin in percentage
	*
	* max_pixel_rate = <>;
	* Max pixel rate in Kpixel/s for the ISP ISO case
	*
	* isp_peak_byte_per_pixel = <>;
	* Max byte per pixel for the ISP ISO case
	*
	* isp_bw_margin_pct = <>;
	* Isp bandwidth margin in percentage
	*/
	num_csi_lanes = <4>;
	max_lane_speed = <1500000>;
	min_bits_per_pixel = <10>;
	vi_peak_byte_per_pixel = <2>;
	vi_bw_margin_pct = <25>;
	max_pixel_rate = <750000>;
	isp_peak_byte_per_pixel = <5>;
	isp_bw_margin_pct = <25>;

	/**
	 * The general guideline for naming badge_info contains 3 parts, and is as follows,
	 * The first part is the camera_board_id for the module; if the module is in a FFD
	 * platform, then use the platform name for this part.
	 * The second part contains the position of the module, ex. "rear" or "front".
	 * The third part contains the last 6 characters of a part number which is found
	 * in the module's specsheet from the vender.
	 */
	modules {
		module0 {
			badge = "e2832_ltx6911";
			position = "bottom";
			orientation = "1";
			drivernode0 {
				/* Declare PCL support driver (classically known as guid)  */
				pcl_id = "v4l2_sensor";
				/* Driver v4l2 device name */
				devname = "e2832 2-002b";
				/* Declare the device-tree hierarchy to driver instance */
				proc-device-tree = "/proc/device-tree/i2c@31e0000/e2832@2b";
			};
		};
	};
};

};

Kind Regards,

Dan

hello dan.riches,

first of all, we do not support 8-lane by default.
if that’s possible, please narrow down the issue with 4-lane configuration.

may I know how you validate this?
did you meant you’ve probe the MIPI signaling on the CSI channel?

Hi Jerry,

This was going to be compiled for a TX2 module but we’ve decided to stick with the Xavier NX for now, and that was where the 8 lanes came from. I’ll change that back to 4. I validated the chips output with a scope and checked the levels etc etc, as I’m an electronics engineer predominantly but also do software / firmware.

Going through the dtsi’s again I can see area’s that maybe wrong as follows and I’d be very grateful if you can confirm please?

In /dev the chip appears as lt6911uxc and not e2832, so I’m thinking that this line is wrong: proc-device-tree = “/proc/device-tree/i2c@31e0000/e2832@2b”;
and also this line devname = “e2832 2-002b”;

Does the remote-endpoint part “remote-endpoint = <&e2832_out0>;” also need to change to lt6911uxc or is that linking to a node within the dtsi and not the device node names (from the driver)?

EDIT I’ve changed all instances of e2832 to lt6911uxc to be sure and changed the lane config to 4, I’m recompiling this to check it out. Only the filename of the dtsi is kept as e2832 and the include reference to it still has this naming convention.

Any assistance or pointers are extremely appreciated as I’m certain I’m so close to getting this working.

Many Thanks, Dan

Hi Jerry,

I’ve made changes so that all names referring to e2832 are now called lt6911uxc, the lane config is now 4 and I’ve recompiled everything. The error is still the same as before unfortunately. VVDN, the supplier of the carrier board do not seem to want to help without spending more money than we have available so any pointers etc would be really appreciated.

Also to add that the Lontium chip has new firmware from Lontium themselves sepcifically for me so the chip outputs MIPI on a valid HDMI input source. Is this ok to do?

Kind Regards,

Dan

hello dan.riches,

may I know which Jetpack release version you’re working with.
please have sanity check with v4l2-compliance test.

for testing,
you may also give it a try with below commands to boost all the VI/CSI/ISP clocks.
for example,

sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate

besides,
please also disassembler the dtb file into text file for quick checking.
for instance,
$ dtc -I dtb -O dts -o temp.txt tegra194-xxx.dtb

Hi Jerry,

I’m using Jetpack 5.1.1 / R35.4.1 as that one has the lt6911uxc driver which according to forum posts works for them hence I chose it for stability, commonality and it’s more likely to work. Kernel version is 5.10.120 if that helps at all.

I have added some files here as requested and I’ve also included the text output when running the dtc decompile on the file on the host machine under ~/Linux_for_Tegra/kernel/dtb/tegra194-p3668-0000-p3509-0000.dtb.

dtc_decompile_messages_output.txt (40.0 KB)
temp.txt (392.9 KB)
v4l2-compliance_test.txt (3.4 KB)

I tried the clock boosting and that still gave me the same errors in dmesg which is a shame. I really do think I’ve missed something crucial in the device tree which I just can’t seem to find, I think I’m going code blind lol!

Thanks for all your assistance Jerry it’s greatly appreciated!

Kind Regards, Dan

hello dan.riches,

you may dig into below for VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF IOCTL failures.

Buffer ioctls (Input 0):
		fail: v4l2-test-buffers.cpp(715): q.create_bufs(node, 1, &fmt) != EINVAL
	test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL

by checking your device tree.
(1) this is incorrect settings, csi_pixel_bit_depth = "24"; you should configure it as 8 per your settings.
(2) may I know how many cameras in your system? do you have rbpcv2_imx219_c? if no, please remove it from tegra-capture-vi, nvcsi and also tegra-camera-platform.
(3) following above, if you do have rbpcv2_imx219_c please check Module Properties for updating position property accordingly.

Hi Jerry,

After looking some more I can see that the BCT config for the MIPI port on J11 of this carrier board by VVDN is wrong. I’ll correct that and the pixel bit depth setting over the next day or so and get back to you, hopefully once that’s done it’ll start working or at least get further along the compliance tests.

Thanks for your assistance of late and hopefully I’ll have some good news rather than more questions lol.

Kind Regards,

Dan

Hi Jerry,

I found that I’d missed off one step in the instructions from VVDN to get the pinmux and padvoltage device tree configuration applied using the spreadsheet and python program to generate the dtsi files. I sorted this out and reflashed the system only to find that the Lontium driver is now failing to load. This is proving to be a real headache for me to be honest. I’ve added the kernel output text from dmesg below so if you have any ideas that would be greatly appreciated:

[ 11.105993] tegra-hda 3510000.hda: Adding to iommu group 32
[ 11.106590] tegra-hda 3510000.hda: Override SDO lines to 4
[ 11.110910] lt6911uxc 8-002b: probing lt6911uxc v4l2 sensor at addr 0x2b
[ 11.111037] lt6911uxc 8-002b: mclk absent,assuming sensor driven externally
[ 11.112510] lt6911uxc 8-002b: supply vana not found, using dummy regulator
[ 11.114205] lt6911uxc 8-002b: supply vdig not found, using dummy regulator
[ 11.115471] lt6911uxc 8-002b: supply vif not found, using dummy regulator
[ 11.116778] extract_pixel_format: Need to extend formatrgb_rgb8888
[ 11.118021] lt6911uxc 8-002b: Unsupported pixel format
[ 11.118025] lt6911uxc 8-002b: Failed to read mode0 image props
[ 11.118032] lt6911uxc 8-002b: Could not initialize sensor properties.
[ 11.118036] lt6911uxc 8-002b: Failed to initialize lt6911uxc
[ 11.118039] lt6911uxc 8-002b: tegra camera driver registration failed
[ 11.118374] lt6911uxc: probe of 8-002b failed with error -22

This change includes changing the dtsi from 24 to 8 in the following line:
csi_pixel_bit_depth = “24”;
Changed to:
csi_pixel_bit_depth = “8”;

I also removed the includes for the IMX219 and IMX477 camera dtsi’s as requested and they no longer appear to be probed on boot up.

I forgot to add that we only have one MIPI device attached, the LT6911UXC, connected to this will be a HDMI port switch to select between 2 HDMI sources; ordinary HDMI and HDMI from a HD-SDI board which we’re not using yet. This will be controlled / switched using i2c and gpio pins so it doesn’t affect any drivers / device tree configs etc.

Kind Regards,

Dan

Hi Jerry,

The change to the csi_pixel_bit_depth was wrong and causes the Lontium driver to fail to load entirely. I’ve reverted this part and it now loads correctly. However, even with the correct pinmux and padvoltage settings applied I still have the same errors in dmesg.

I’ve also noticed that running v4l2-ctl --list-formats results in:
dan@dan-nvidia:~$ v4l2-ctl --list-formats -d /dev/video0
ioctl: VIDIOC_ENUM_FMT
Type: Video Capture

[0]: 'AB24' (32-bit RGBA 8-8-8-8)

This seems wrong to me and is possibly why my capture command is failing, what do you think?

I’d be grateful if you have any ideas on where to look so I can make some progress at least…

Kind Regards,

Dan

hello dan.riches,

it looks you’re now able to probe lt6911uxc as video node, right?

we don’t support RGB888 by default, you may have implementation to extend the supported sensor types.
but… in my experience, it should be AR24 instead of AB24.
FYI, even though there’s RGB888 format definition in kernel layer, VI engine did not support RGB888 memory formats due to it’ll add luminance format.
i.e. V4L2_PIX_FMT_ABGR32, or AR24.

Hi Jerry,

In that case I can ask Lontium to produce different firmware for us. What is the best format to use?

Kind Regards,

Dan

hello dan.riches,

BTW,
could you please also check you’ve below code snippet included,
for instance,

diff --git a/drivers/media/platform/tegra/camera/vi/vi5_formats.h b/drivers/media/platform/tegra/camera/vi/vi5_formats.h

@@ -118,7 +118,7 @@ static const struct tegra_video_format vi5_video_formats[] = {
 
        /* RGB888 */
        TEGRA_VIDEO_FORMAT(RGB888, 24, RGB888_1X24, 4, 1, T_A8R8G8B8,
-                               RGB888, ABGR32, "BGRA-8-8-8-8"),
+                               RGB888, RGBA32, "RGBA-8-8-8-8"),

Hi Jerry,

I’ve checked the vi5_formats.h and it has that change already so that won’t help me unfortunately!

Would it be better if I changed everything to YUV422? I can ask Lontium to produce the firmware for that and as the VI doesn’t support RGB888 I feel this would be a better option. What are your thoughts?

Kind Regards,

Dan

yes, that will be better approach by sending YUV422.
FYI, we generally capture YUV422 such as UYVY or YUYV through v4l2src.

Hi Jerry,

I’m getting the same NULL issue that I started with when using RGB888 so I think I need to correct some settings in the device tree. Lontium have said the output format is YUV422 8bit UYVY, would you mind confirming the csi_pixel_bit_depth setting please? I’m thinking this is 16 but could be wrong.

Also how do I calculate the pixel_clk_hz value so it’s correct for 1920x1080p60? I’ll need to calculate this for the 2 other modes as well 3840x2160p30 and 1280x768p60 so It’d be better if I know how to calculate them properly I imagine.

Kind Regards,

Dan

hello dan.riches,

please refer to Sensor Pixel Clock section for several formulas to evaluate sensor pixel clock, please note it must be set correctly to avoid potential issues.

csi_pixel_bit_depth it’s the bit depth of sensor output on the CSI bus. it should be 8 per your use-case.

Hi Jerry,

I made the changes to the csi_pixel_bit_depth to 8 on all 3 modes in the dtsi file which I’ve attached and now you can see in the dmesg kernel output (also attached) that there is a problem with that bit depth for yuv and uyvy encoding. Each time I use an 8bit bit depth I get this same error, why is that? Is it not supported and I need to get Lontium to produce 16bit yuv firmware?

The error I’m getting is below so you don’t have to wade through the full text file, if I have the bit depth set to 16 then the driver loads fine just never when I use a bit depth of 8:
[ 12.460168] extract_pixel_format: Need to extend formatyuv_uyvy8
[ 12.460174] lt6911uxc 8-002b: Unsupported pixel format
[ 12.460178] lt6911uxc 8-002b: Failed to read mode0 image props
[ 12.460186] lt6911uxc 8-002b: Could not initialize sensor properties.
[ 12.460190] lt6911uxc 8-002b: Failed to initialize lt6911uxc
[ 12.460193] lt6911uxc 8-002b: tegra camera driver registration failed
[ 12.462289] lt6911uxc: probe of 8-002b failed with error -22

Thanks for helping me Jerry, I’m absolutely stuck without your assistance.

Kind Regards,

Dan
dmesg_25032024.txt (67.1 KB)
tegra194-camera-jakku-e2832.dtsi.txt (11.6 KB)

Hi Jerry,

I reverted the change to the csi pixel bit depth to 16 as I checked with Lontium and they said it should be 16bits per pixel. This compiles and the driver loads as normal but I still get the NULL error when testing the capture with a v4l2-ctl command.

I then checked the MIPI data again with a scope and saw that the data rate is actually really slow and this doesn’t change if I force the Raspberry Pi to output YCbCr (YUV422) or leave it in the default RGB output. I’ve asked Lontium about this and await their reply which I’ll add to the forum so hopefully the notes will be useful to others including me.

It is rather unfortunate that of all the other forum users I’ve asked, that have used the Lontium chip, won’t reply or let me see their final dtsi file for reference at least. Keeping helpful information to oneself is detrimental to open source and goes against the grain to me, very unhelpful!! Thanks for your help though, I really do appreciate it!

Can you check my dtsi file and see if it’s correct please as I personally think, probably wrongly, that I have selected the wrong CSI port which is why it’s giving a NULL error. VVDN have said that I should use tegra_sinterface=“serial_e” which seems to map to CSI port 4.

Kind Regards,

Dan

Hi Jerry, and anyone else that can give me some input,

In my dtsi file I have a section called “tegra-capture-vi” but it has no address, so should it be vi@15c10000 instead? Is this why I’m still getting the NULL error despite everything else being absolutely perfect imho.

I’ve also sorted out the clock setting in the device tree which should be 148488000Hz for 1920x1080p50 as the whole region that the chip reported is 2640x1125 (seen on serial debug output from the chip)

One question for you; if I ask Lontium to produce firmware that outputs 4kp60 and I boost the clocks, is the Xavier NX able to handle that from a single source ie no other cameras in use just the one?

Kind Regards,