I2c mux tca9548 for imx462

Hi @JerryChang,
No its not being detected, nor even trying to probe.
Attached two dmesg files. one without the tca9548 mux running (but I had to open the mux in the previus reboot):
dmesg_imxworks.txt (61.5 KB)

this on has:

[ 6.313602] pca953x 8-0022: using AI

(this is the i2c IO EXPENDER (tca6424_22_a) ! not the mux)
and:

[ 8.100785] [IMX462]: (imx462) probing v4l2 sensor.

The other is with the tca9548, but now the imx462 doesn’t work.
dmesg_imx_not_works.txt (62.0 KB)

and this one has

[ 6.707710] pca954x 8-0070: pca954x_probe()

[    6.707710] pca954x 8-0070: pca954x_probe() 2 
[    6.708256] pca954x 8-0070: supply vcc-pullup not found, using dummy regulator
[    6.708709] pca954x 8-0070: pca954x_probe: forcing device bus number, start 30.
[    6.708982] pca954x 8-0070: device detect skipped.
[    6.709168] pca954x 8-0070: pca954x_init() as builtin
[    6.709335] pca954x 8-0070: pca954x_init(addr=112, data->last_chan=0)
[    6.710270] i2c i2c-8: Added multiplexed i2c bus 30
[    6.713287] i2c i2c-8: Added multiplexed i2c bus 31
[    6.718223] i2c i2c-8: Added multiplexed i2c bus 32
[    6.722947] i2c i2c-8: Added multiplexed i2c bus 33
[    6.727634] i2c i2c-8: Added multiplexed i2c bus 34
[    6.732829] i2c i2c-8: Added multiplexed i2c bus 35
[    6.737205] i2c i2c-8: Added multiplexed i2c bus 36
[    6.742316] i2c i2c-8: Added multiplexed i2c bus 37
[    6.747005] pca954x 8-0070: registered 8 multiplexed busses for I2C switch pca9548

I2C switch pca9548 has register, but the later device should be i2c bus 30.
hecne,
please revise below for testing.

The dmesg I sent was before changing to 80.
you can see in my second thread that I changed it from 0x1e (30) to 80.
it doesn’t work either way. when I start the bus in 30, and devname = "eimx462 30-0042";
or when I start at 80 and devname = "eimx462 80-0042";

hello matanh,

please add some debug prints to your sensor driver, is the sensor power_on/off being called?

this is camera, and there is debug on the probing. do you have other ideas where else I can add debugging?
[IMX462]: (imx462) probing v4l2 sensor.

I added printf to some more internal functions:
cam_power_on(), cam_power_off(), cam_power_put(), cam_power_get()
still no output

hello matanh,

there should be sensor operations called by probing process.
you may check reference drivers as an example,

static struct camera_common_sensor_ops imx185_common_ops = {
        .numfrmfmts = ARRAY_SIZE(imx185_frmfmt),
        .frmfmt_table = imx185_frmfmt,
        .power_on = imx185_power_on,
        .power_off = imx185_power_off,
        .write_reg = imx185_write_reg,
        .read_reg = imx185_read_reg,
        .parse_dt = imx185_parse_dt,
        .power_get = imx185_power_get,
        .power_put = imx185_power_put,
        .set_mode = imx185_set_mode,
        .start_streaming = imx185_start_streaming,
        .stop_streaming = imx185_stop_streaming,
};

Hello Jerry.
As told here:

I have added printf to this functions.
and there is no printing of any when the imx is inside the pca9548.

Do you know how the scanning of the device tree works? for example, does the tegra-camera-platform try to find only cameras that are on proc-device-tree.
Or if there other method that might be debugged to understand the process and when it fails?

hello matanh,

there’ll be error reported once registration has failed.

FYI,
there’s Jetson V4L2 Camera Framework to register sensor device as V4L2 sub-device.
and… it initialize an instance of camera device (i.e. tc_dev) and calling those common operations as point-out in comment #19.

is the video node, /dev/video* created?
please running below to examine media controller settings, $ sudo media-ctl -p -d /dev/media0

I will be able to check what you suggested next week.
meanwhile, do you think it worth to use CONFIG_DYNAMIC_DEBUG for this issue?

hello matanh,

CONFIG_DYNAMIC_DEBUG also enable the capability to enable/disable dev_dbg() from user-space.
you may give it a try, however, those prints regarding to registration has failed all using with dev_err

Here, When the IMX doesn’t loaded:

xx@xx-desktop:~$ sudo media-ctl -p -d /dev/media0
Media controller API version 5.10.104

Media device information
------------------------
driver          tegra-camrtc-ca
model           NVIDIA Tegra Video Input Device
serial
bus info
hw revision     0x3
driver version  5.10.104

Device topology
- entity 1: 13e10000.host1x:nvcsi@15a00000- (2 pads, 0 link)
            type V4L2 subdev subtype Unknown flags 0
        pad0: Sink
        pad1: Source

And here when the imx works:

xx@xx-desktop:~$ sudo media-ctl -p -d /dev/media0
Media controller API version 5.10.104

Media device information
------------------------
driver          tegra-camrtc-ca
model           NVIDIA Tegra Video Input Device
serial
bus info
hw revision     0x3
driver version  5.10.104

Device topology
- entity 1: 13e10000.host1x:nvcsi@15a00000- (2 pads, 2 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev0
        pad0: Sink
                <- "eimx462 8-0042":0 [ENABLED]
        pad1: Source
                -> "vi-output, eimx462 8-0042":0 [ENABLED]

- entity 4: eimx462 8-0042 (1 pad, 1 link)
            type V4L2 subdev subtype Sensor flags 0
            device node name /dev/v4l-subdev1
        pad0: Source
                [fmt:SGBRG12_1X12/1920x1080 field:none colorspace:srgb]
                -> "13e10000.host1x:nvcsi@15a00000-":0 [ENABLED]

- entity 6: vi-output, eimx462 8-0042 (1 pad, 1 link)
            type Node subtype V4L flags 0
            device node name /dev/video0
        pad0: Sink
                <- "13e10000.host1x:nvcsi@15a00000-":1 [ENABLED]

hello matanh,

it’s media-ctl to verify the port binding results.
please review Port Binding section to check the port binding for VI (video input), NvCSI, and sensor modules.

Hello again.
The device tree is already attached. (I must say that I don’t understand the ping-pong. I tried to put all the data in the firsts threads, but I keep asked about info I already give.)

The manual tree, and the examples on the kernel doesn’t match. this is the manual:

vi {
    num-channels = <1>;
        ports {
        #address-cells = <1>;
        #size-cells = <0>;
            port@0 {
                reg = <0>;
                liimx185_vi_in0: endpoint {
                port-index = <2>;
                bus-width = <4>;
                remote-endpoint = <&liimx185_csi_out0>;
            };
        };
    };
};

nvcsi {
    num-channels = <1>;
    #address-cells = <1>;
    #size-cells = <0>;
    channel@0 {
        reg = <0>;
        ports {
            #address-cells = <1>;
            #size-cells = <0>;
            port@0 {
                reg = <0>;
                liimx185_csi_in0: endpoint@0 {
                    port-index = <0>;
                    bus-width = <4>;
                    remote-endpoint = <&liimx185_imx185_out0>;
                };
            };
            port@1 {
                reg = <1>;
                liimx185_csi_out0: endpoint@1 {
                    remote-endpoint = <&liimx185_vi_in0>;
                };
            };
        };
    };
};

But in the kernel itself its: (I took the imx318 as example)

tegra-capture-vi {
		num-channels = <1>;
		ports {
			#address-cells = <1>;
			#size-cells = <0>;
			port@0 {
				reg = <0>;
				e3331_vi_in0: endpoint {
					port-index = <0>;
					bus-width = <3>;
					remote-endpoint = <&e3331_csi_out0>;
				};
			};
		};
	};

	host1x@13e00000 {
		nvcsi@15a00000 {
			num-channels = <1>;
			channel@0 {
				reg = <0>;
				ports {
					#address-cells = <1>;
					#size-cells = <0>;
					port@0 {
						reg = <0>;
						e3331_csi_in0: endpoint@0 {
							port-index = <0>;
							bus-width = <3>;
							remote-endpoint = <&e3331_imx318_out0>;
						};
					};
					port@1 {
						reg = <1>;
						e3331_csi_out0: endpoint@1 {
							remote-endpoint = <&e3331_vi_in0>;
						};
					};
				};
			};
		};
	};

again:
vi->port@0->liimx185_vi_in0: endpoint
nvcsi->channel@0->port@0->liimx185_csi_in0: endpoint@0
_________________->port@1->liimx185_csi_out0: endpoint@1

vs

tegra-capture-vi->ports ->port@0->e3331_vi_in0: endpoint
host1x@13e00000 ->nvcsi@15a00000->channel@0 ->ports->port@0 ->e3331_csi_in0: endpoint@0
__________________________________________________________port@1->e3331_csi_out0: endpoint@1

I guess the 'kernel ’ version is correct

you’re checking wrong sources, E3331 it’s actually the camera board with IMX318 camera sensor.

The same hierarchy is in the ‘tegra194-camera-rbpcv2-imx219.dtsi’ too. and in all the other dt for cameras. the E3331 IMX318 was only one example.

the documentation just don’t fit the code

hello matanh,

as I checking the path, it’s under i2c@3180000.
is it device tree overlays to overwrite your settings? please also examine the sysnodes.
for example,
$ cat proc/device-tree/__symbols__/tca95*
/i2c@3180000/tca9546@70
/i2c@3180000/tca9548@77

 xx@xx-desktop:~$ cat proc/device-tree/__symbols__/tca95*
 cat: 'proc/device-tree/__symbols__/tca95*': No such file or directory

I guess you ment:

xx@xx-desktop:~$ cat /proc/device-tree/__symbols__/tca9548_70
/i2c@31e0000/tca9548@70xx@xx-desktop:~$

@JerryChang , any ideas?

hello matanh,

that’s something wrong with the device topology,
is it device tree overlays to overwrite your settings? please try removing all overlay files for testing, i.e. /boot/*.dtbo