1

I am a bit confused with behavior of Jetson TX2 when loading drivers for camera.

Here is definition of IMX274 in device tree:

i2c@3180000 {
        reg = <0x0 0x3180000 0x0 0x100>;
        dmas = <0x19 0x17 0x19 0x17>;
        interrupts = <0x0 0x1b 0x4>;
        compatible = "nvidia,tegra186-i2c";
        clock-names = "div-clk", "parent", "slow-clk";
        reset-names = "i2c";
        clock-frequency = <0x61a80>;
        scl-gpio = <0x12 0x72 0x0>;
        sda-gpio = <0x12 0x73 0x0>;
        clocks = <0xd 0x4b 0xd 0x10d 0xd 0x5c>;
        resets = <0xd 0x15>;
        status = "okay";
        #address-cells = <0x1>;
        phandle = <0x7c>;
        #stream-id-cells = <0x1>;
        #size-cells = <0x0>;
        dma-names = "rx", "tx";
        linux,phandle = <0x7c>;

        imx274_a@1a {
                reg = <0x1a>;
                mclk = "extperiph1";
                devnode = "video0";
                avdd-reg = "vana";
                compatible = "nvidia,imx274";
                clock-names = "extperiph1", "pllp_grtba";
                reset-gpios = <0x12 0x8d 0x0>;
                physical_h = "2.738";
                physical_w = "3.674";
                clocks = <0xd 0x59 0xd 0x10d>;
                vana-supply = <0x1a>;
                sensor_model = "imx274";
                iovdd-reg = "vif";
                delayed_gain = "true";
                vif-supply = <0x1a>;
                dvdd-reg = "vdig";
                vdig-supply = <0x1a>;

                mode0 {
                    ...
                }

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

                        port@0 {
                                reg = <0x0>;

                                endpoint {
                                        bus-width = <0x4>;
                                        remote-endpoint = <0x1d>;
                                        phandle = <0x94>;
                                        csi-port = <0x0>;
                                        linux,phandle = <0x94>;
                                };
                        };
                };
        };

i2c2 is an alias for i2c@3180000 therefore I expect to see the device on bus 2. An sure I can see it on a bus with address 0x57.

nvidia@tegra-ubuntu:~/kernel/kernel$ sudo i2cdetect -r -y 2
[sudo] password for nvidia: 
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- UU -- -- -- -- -- 
20: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

Here comes the first question. How does kernel identifies type of i2c device on a bus? I thought that field reg is used, but 0x1a in device tree is clearly different from 0x57 on a bus.

Secondly, as I can see module is compatible with the following drivers: compatible = "nvidia,imx274"; However device driver is different:

nvidia@tegra-ubuntu:~/kernel/kernel$ sudo v4l2-ctl -D -d /dev/video0
Driver Info (not using libv4l2):
        Driver name   : tegra-video
        Card type     : vi-output, imx274 2-001a
        Bus info      : platform:15700000.vi:0
        Driver version: 4.4.38
        Capabilities  : 0x84200001
                Video Capture
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps   : 0x04200001
                Video Capture
                Streaming
                Extended Pix Format

Therefore it seems for me that wrong driver is loaded for some reasons, it it true or I am just missing something? However it is still possible to capture image with argus.

Improve this question
3
  • I'm no expert, so some part is just guessing. For example, I don't know how the driver is connected to the CSI port. The I2C address is probably hardcoded in the driver, because it is fixed to the image sensor. i2cdetect does only probe randomly, without knowing the device tree, so no magic here. And are you sure about compatible = "nvidia,imx274", not "sony,imx274"? Isn't that a Sony driver?
    – Philippos
    Jul 30, 2019 at 10:34
  • @Philippos yep, there is built-in driver in kernel and I am pretty sure about this compatible string, it is just copy-pasted from currently used dtb/dts file. So I2C core just populates all the described devices no matter of their presence? Also still missing why driver is different from that of compatible string.
    – Юрий Камнев
    Jul 30, 2019 at 10:56
  • 1) As long as the device tree does the correct MUXing for the I2C pins and the naked I2C driver is loaded (which is probably default), i2cdetect can probe for devices independent from actual devices being present or higher-level drivers being loaded. Mainly just trying each address and checking for an ACK. 2) To my knowledge, the compatible is checked against identifiers different from the driver name. A driver can call itself foo but get triggered by compatible,bar
    – Philippos
    Jul 30, 2019 at 11:14

1 Answer 1

Reset to default
0

some random answers :

reg = <0x1a> in the dts file is the address, not the type, of the peripheral on the i2c bus. Because that address is registered by the driver, it won't be probed by i2c-detect, hence the 'UU' at address 1a in i2c-detect's output. The '57' in your output is another peripheral.

in nvidia TX2 v4l2 world, /dev/video0 refers to the driver of the VI which is connected to the CSI which your sensor is connected to. 'imx274 2-001a' in the output of 'v4l2-ctl -D' tells you that that VI is connected to a imx274 located on the 2nd (arbitrary linux-kernel ordering) i2c bus, at the address 0x1a.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.