V4l2 [v4l-utils] commands hang on TX2 NX with lt6911uxc

Hello,

I’m using a Jetson TX2 NX SOM on a custom carrier board with the Lontium lt6911uxc chip, and while the kernel log output and I2C comms look good I’m not able to use any of the v4l2 commands (v4l2-ctl, v4l2-dbg, and v4l2-compliance). Any of those commands will hang immediately, and we’re not certain if the issue is with the device tree or with something else.

An example of trying a v4l2 command:

user@devhost:~$ v4l2-dbg -d /dev/video0 -n --verbose

The empty line at the end is all we see on our end, and the return from ps aux | grep v4l2 shows the v4l2 command in state ‘D+’.

Our dmesg output for the chip looks fine to us:

user@devhost:~$ dmesg | grep lt6911
[   13.490317] lt6911uxc 9-002b: probing lt6911uxc v4l2 sensor at addr 0x2b
[   13.499652] lt6911uxc 9-002b: mclk absent,assuming sensor driven externally 
[   13.512244] lt6911uxc 9-002b: tegracam sensor driver:lt6911uxc_v2.0.6
[   13.514697] tegra-vi4 15700000.vi: subdev lt6911uxc 9-002b bound
[   13.525009] Modules linked in: lt6911uxc(+) nvgpu ip_tables x_tables
[   13.714031] [<ffffff8000f8ba2c>] lt6911uxc_probe+0x124/0x238 [lt6911uxc]
[   13.765852] [<ffffff8000f8f018>] lt6911uxc_i2c_driver_init+0x18/0x30 [lt6911uxc]
[   15.296919] Modules linked in: zram userspace_alert lt6911uxc(+) nvgpu ip_tables x_tables

And here’s our (decompiled) device tree for the i2cmux and lt6911uxc:

        cam_i2cmux {
                compatible = "i2c-mux-gpio";
                #address-cells = <0x1>;
                #size-cells = <0x0>;
                i2c-parent = <0x45>;
                mux-gpios = <0x21 0x14 0x0>;

                i2c@0 {
                        clock-frequency = <0x186a0>;
                        reg = <0x0>;
                        #address-cells = <0x1>;
                        #size-cells = <0x0>;
                        linux,phandle = <0x159>;
                        phandle = <0x159>;

                        lt6911uxc_a@2b {
                                compatible = "nvidia,lt6911uxc";
                                reg = <0x2b>;
                                status = "okay";
                                devnode = "video0";
                                reset-gpios = <0x21 0x69 0x1>;
                                interrupt-parent = <0x23>;
                                interrupts = <0x32 0x4>;
                                linux,phandle = <0x15a>;
                                phandle = <0x15a>;

                                ports {
                                        #address-cells = <0x1>;
                                        #size-cells = <0x0>;

                                        port@0 {
                                                ret = <0x0>;
                                                status = "okay";

                                                endpoint {
                                                        status = "okay";
                                                        port-index = <0x0>;
                                                        bus-width = <0x4>;
                                                        remote-endpoint = <0xd0>;
                                                        linux,phandle = <0x4d>;
                                                        phandle = <0x4d>;
                                                };
                                        };
                                };
                        };
                };
        };

hello miles.heaton,

please look into your lt6911uxc driver for probing process. please dig into where cause the hang.

Continued debugging, discovered that the root cause lied within the device tree.

After following the work done at Device Tree for CSI MIPI - #26 by yuyeo0605, I added the mode0 definition to the lt6911uxc section and was able to get some output from v4l2.

v4l2-ctl still hangs when trying to capture an image, but our errors look exactly like what’s at Got "PXL_SOF syncpt timeout! err ".

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