Unable to configure MIPI/CSI2

[aliismail]

So I am at a point where I have configured the mipi/cis2 interface. I am trying to configure VC2 to CSI0 in IPU2.

In imx6dql.dtsi the mipi/csi interface is defined.

mipi_csi: mipi_csi@021dc000 { /* MIPI-CSI */

                                compatible = "fsl,imx6q-mipi-csi2";

                                reg = <0x021dc000 0x4000>;

                                interrupts = <0 100 0x04>, <0 101 0x04>;

                                clocks = <&clks IMX6QDL_CLK_HSI_TX>,

                                         <&clks IMX6QDL_CLK_EMI_SEL>,

                                         <&clks IMX6QDL_CLK_VIDEO_27M>;

                                clock-names = "dphy_clk", "pixel_clk", "cfg_clk";

                                status = "disable";

                        };

In imx6dqscm_qwks_rev2.dts the mipi/csi is configured with IPU2(ipu_id = 1), CSI0(csi_id = 0), VC2 (v_channel=2) and 1 lane.

&mipi_csi {

        status = "okay";

        ipu_id = <1>;

        csi_id = <0>;

        v_channel = <2>;

        lanes = <1>;

};

IPU2 is also defined and configured already in imx6qdl.dtsi. My issue is that when I read memory address 0x021dc004 (MIPI_CSI_N_LANES) I get 0x00000003, which means there are 4 active data lanes. After looking at the rest of the registers, everything is in reset. Any hints on why everything is in reset and/or what I have to configure to get it out of reset?

[jimmychan]

Have you load the MIPI camera driver/module?

[aliismail]

I can see in dmesg that the MIPI CSI2 driver is loaded and it probes the MIPI/CSI2 interface. I can see the values that I set in my device tree are properly read by the kernel driver, but I'm not sure the functions that setup the lanes or virtual channels get used after probing. This might be a dumb question, but what is supposed to make the calls to configure Mipi/Csi such as mipi_csi2_set_lanes? Nothing calls this function and I am not sure if I am missing a step. I am not even sure how this kernel module is being loaded and probed. My guess is the kernel must have been configured to do so.