Can't get video data through LT6911C(HDMI to MIPI Transmitter) (2 lanes mipi)

  1. I removed the I2C operation in the IMX219 driver and can see the /dev/video node
  2. I modified the tegra194-camera-rbpcv2-imx219.dtsi, only one mode0, and formulated YUV

I tried the command:
v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=YUYV --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=yuv.raw

This v4l2-ctl will halt, can’t get the frame data.

The kernel reports the following error:

[ 2310.905736] tegra194-vi5 corr_err: discarding frame 0, flags: 102, err_data 12583008
[ 2310.922241] tegra194-vi5 corr_err: discarding frame 0, flags: 96, err_data 12583008
[ 2310.922466] [RCE] Configuring VI GoS.
[ 2310.922481] [RCE] VM GOS[#0] addr=0xc2100000
[ 2310.922517] [RCE] VM GOS[#1] addr=0xc2101000
[ 2310.922538] [RCE] VM GOS[#2] addr=0xc2102000
[ 2310.922545] [RCE] VM GOS[#3] addr=0xc2103000
[ 2310.922551] [RCE] VM GOS[#4] addr=0xc2104000
[ 2310.922558] [RCE] VM GOS[#5] addr=0xc2105000
[ 2310.922568] [RCE] vi5_hwinit: firmware CL2018101701 protocol version 2.2
[ 2310.922580] [RCE] VI GOS[#0] set to VM GOS[4] base 0xc2104000
[ 2310.955663] tegra194-vi5 corr_err: discarding frame 0, flags: 160, err_data 160
[ 2310.955864] tegra194-vi5 corr_err: discarding frame 0, flags: 224, err_data 12583008

my dts:
mode0 { /* IMX219_MODE_1920x1080_30FPS */
mclk_khz = “24000”;
num_lanes = “2”;
tegra_sinterface = “serial_a”;
phy_mode = “DPHY”;
discontinuous_clk = “yes”;
dpcm_enable = “false”;
cil_settletime = “0”;

				/*[  207.311817] act:1920x1080, total:2200x1125, pixclk:148488000, fps:0
				[  207.311821] hfp:88, hs:44, hbp:148, vfp:2, vs:5, vbp:38, inerlaced:0 */

				active_w = "2200"; //"1920";
				active_h = "1125"; //"1080";
				mode_type = "yuv";
				pixel_phase = "yuyv";
				csi_pixel_bit_depth = "16";
				readout_orientation = "0";
				line_length = "2200";
				inherent_gain = "1";
				mclk_multiplier = "6.20"; //"9.33";
				pix_clk_hz = "148488000"; /*"182400000";  */

				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 = "30000000"; /* 30.0 fps */
				step_framerate = "1";
				default_framerate = "30000000"; /* 30.0 fps */
				min_exp_time = "13"; /* us */
				max_exp_time = "683709"; /* us */
				step_exp_time = "1";
				default_exp_time = "2495"; /* us */

				embedded_metadata_height = "2";

Enable the trace to get more information:
t.log (34.4 MB)


suggest you should check tc358840 since it’s reference HDMI2CSI driver.
however, you might be close to it, the port bindings should be okay, the VI reports discarding frame messages it indicate VI has dropping the capture buffers.

please revise embedded_metadata_height as zero if your MIPI package did not obtain embedded data.
please also share the device tree settings of tegra-camera-platform{}.

hello Jerry
Thank you for replying, after I change embedded_metadata_height to 0, the same error. The attachment is my tegra-camera-platform (according to the information from the supplier, I set the frame rate to 60fps)

tegra194-camera-rbpcv2-imx219.dtsi (21.6 KB)


since you’re based-on rbpcv2_imx219_a to revise the code, you should also update those property settings in tegra-camera-platform{}
for example,
you should at least update badge since it’s an unique name that identifies this module.
devname property used to identify the driver sources, you may update this or have the same string in your driver code.
the path of proc-device-tree should also be revised accordingly.

		modules {
			cam_module0: module0 {
				badge = "jakku_front_RBP194";
				position = "front";
				orientation = "1";
				cam_module0_drivernode0: drivernode0 {
					pcl_id = "v4l2_sensor";
					devname = "imx219 9-0010";
					proc-device-tree = "/proc/device-tree/cam_i2cmux/i2c@0/rbpcv2_imx219_a@10";

hello Jerry

I only used one camera and nothing else, refer to this note" ”, —“If your system has multiple identical modules, each module must have a different position, making the module name unique.” So I didn’t modify it.

The attachment is my driver file.
imx219.c (30.8 KB)

hello Jerry
My current Jetpack version is JetPack 4.6[rev.3] Do I need to upgrade the version?


you may stay at JP-4.6 for development.
BTW, what’s the format dump shows, i.e. $ v4l2-ctl -d /dev/video0 --list-formats-ext

hello Jerry

a@a-desktop:~$ v4l2-ctl -d /dev/video0 --list-formats-ext
Index : 0
Type : Video Capture
Pixel Format: ‘YUYV’
Name : YUYV 4:2:2
Size: Discrete 3264x2464
Interval: Discrete 0.048s (21.000 fps)
Size: Discrete 3264x1848
Interval: Discrete 0.036s (28.000 fps)
Size: Discrete 1920x1080
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 1640x1232
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 1280x720
Interval: Discrete 0.017s (60.000 fps)

    Index       : 1
    Type        : Video Capture
    Pixel Format: 'YUYV'
    Name        : YUYV 4:2:2
            Size: Discrete 3264x2464
                    Interval: Discrete 0.048s (21.000 fps)
            Size: Discrete 3264x1848
                    Interval: Discrete 0.036s (28.000 fps)
            Size: Discrete 1920x1080
                    Interval: Discrete 0.033s (30.000 fps)
            Size: Discrete 1640x1232
                    Interval: Discrete 0.033s (30.000 fps)
            Size: Discrete 1280x720
                    Interval: Discrete 0.017s (60.000 fps)



those 2200, and 1125 should be line_length and frame_length config.
active_w/active_h are pixel active regions. these device tree configurations mismatch to your format dumps.

you may also try below commands to boost all the clocks for testing.
for example,

sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/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/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

hello Jerry
i try the boost all the clocks, but i get same error.
i change the active_w/active_h to 1080p,
The attachment is my modified DTS. And I converted DTB to DTS, and I also saw that my changes worked.

b@b-desktop:/proc/device-tree/cam_i2cmux/i2c@0/rbpcv2_imx219_a@10/mode0$ cat active_h
1080b@b-desktop:/proc/device-tree/cam_i2cmux/i2c@0/rbpcv2_imx219_a@10/mode0$ cat active_w
1920b@b-desktop:/proc/device-tree/cam_i2cmux/i2c@0/rbpcv2_imx219_a@10/mode0$ cd …
b@b-desktop:/proc/device-tree/cam_i2cmux/i2c@0/rbpcv2_imx219_a@10$ ls
compatible linux,phandle name physical_h ports reset-gpios use_sensor_mode_id
devnode mode0 phandle physical_w reg sensor_model
tegra194-camera-rbpcv2-imx219.dtsi (17.6 KB)
tegra194-p3668-all-p3509-0000.dts (245.3 KB)

v4l2-ctl -d /dev/video0 --list-formats-ext it parse the driver mode table to list all available sensor modes.
device tree mode settings should identical to those settings, and it’s used by user-space library, such as Argus.


are you using the exactly same i2c bus and the sysnode is same as Raspberry Pi imx219?
the best practice is to revise all device tree properties identical to your hardware setup.

hello Jerry
The LT6911C transmitter uses the same I2C bus, but it does not require I2C control and will output 1080p yuv data all the time after power-up.
I’m just going to read some data with I2C to check the status of the LT6911C.


is there a reset mechanism? ideally, you should send a reset before v4l start-stream.

hello Jerry
The hardware can only reset the LT6911C manually, but the software can’t do this.
Now, after boost all the clocks, I can get yuv data. Why do I need to boost all the clocks, which parameter is wrong?


don’t you said boost all the clocks not helps in comment #12? may I know what’s the modification you’ve done so far.
you may also review Sensor Pixel Clock, it’s driver side used this to calculate the exposure and frame rate of the sensor.

hello Jerry
I put active_w to 1920, active_h to 1080 according to your suggestion. And then I vboost all the clocks, and I get the yuv data.

What file are you using for the driver?
kernel/nvidia/drivers/media/i2c/lt6911uxc.c ?
I have seen that dts supports rgb
Can it be used directly?

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.