CAMSS: Cannot use a 4 lanes CSI sensor (IMX214)


#1

I am trying to use an IMX214 sensor with release/qcom-4.14 with not so much success :(.

These are my steps so far:

  1. I have patched the dts with:
    --- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
    +++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
    @@ -268,14 +268,24 @@
     			regulator-always-on;
     		};
     
    +		camera_vddd_1v12: fixedregulator@3 {
    +			compatible = "regulator-fixed";
    +			regulator-name = "camera_vddd";
    +			regulator-min-microvolt = <1120000>;
    +			regulator-max-microvolt = <1120000>;
    +			regulator-always-on;
    +		};
    +
     		cci@a0c000 {
     			status = "ok";
     
    -			camera_rear@60 {
    -				compatible = "ovti,ov7251";
    -				reg = <0x60>;
    +			camera_rear@10 {
    +				compatible = "sony,imx214";
    +				reg = <0x1a>;
     
    -				enable-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>;
    +				flash-gpios = <&msmgpio 21 GPIO_ACTIVE_HIGH>;
    +				shutdown-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>;
    +				af-gpios = <&msmgpio 26 GPIO_ACTIVE_HIGH>;
     				pinctrl-names = "default";
     				pinctrl-0 = <&camera_rear_default>;
     
    @@ -283,16 +293,17 @@
     				clock-names = "xclk";
     				clock-frequency = <24000000>;
     
    -				vdddo-supply = <&camera_vdddo_1v8>;
    -				vdda-supply = <&camera_vdda_2v8>;
    -				vddd-supply = <&camera_vddd_1v5>;
    +				avdd-supply = <&pm8994_l17>;
    +				dvdd-supply = <&camera_vddd_1v12>;
    +				actvdd-supply = <&pm8994_l23>;
    +				dovdd-supply = <&pm8994_lvs1>;
     
    -				status = "disabled";
    +				status = "okay";
     
     				port {
    -					ov7251_ep: endpoint {
    +					imx214_ep: endpoint {
     						clock-lanes = <1>;
    -						data-lanes = <0>;
    +						data-lanes = <0 2 3 4>;
     						remote-endpoint = <&csiphy0_ep>;
     					};
     				};
    @@ -365,9 +376,9 @@
     					reg = <0>;
     					csiphy0_ep: endpoint {
     						clock-lanes = <7>;
    -						data-lanes = <0>;
    -						remote-endpoint = <&ov7251_ep>;
    -						status = "disabled";
    +						data-lanes = <0 1 2 3>;
    +						remote-endpoint = <&imx214_ep>;
    +						status = "ok";
     					};
     				};
     				port@1 {
    @@ -420,6 +431,7 @@
     				vdd_l14_l15-supply = <&pm8994_s5>;
     				vdd_l20_l21-supply = <&pm8994_s5>;
     				vdd_l25-supply = <&pm8994_s3>;
    +				vdd_lvs1_2-supply = <&pm8994_s4>;
     
     				s3 {
     					regulator-min-microvolt = <1300000>;
    @@ -495,8 +507,8 @@
     					regulator-max-microvolt = <2700000>;
     				};
     				l17 {
    -					regulator-min-microvolt = <2500000>;
    -					regulator-max-microvolt = <2500000>;
    +					regulator-min-microvolt = <2700000>;
    +					regulator-max-microvolt = <2700000>;
     				};
     				l18 {
     					regulator-min-microvolt = <2700000>;
    @@ -553,6 +565,10 @@
     					regulator-min-microvolt = <1800000>;
     					regulator-max-microvolt = <1800000>;
     				};
    +				lvs1 {
    +					regulator-min-microvolt = <1800000>;
    +					regulator-max-microvolt = <1800000>;
    +				};
     			};
     		};
     	};
  1. Created a driver for the module

  2. Try to capture frames using this script

    modprobe v4l2-common
    insmod imx214.ko
    sudo media-ctl -d /dev/media0 -l ‘“msm_csiphy0”:1->“msm_csid0”:0[1],“msm_csid0”:1->“msm_ispif0”:0[1],“msm_ispif0”:1->“msm_vfe0_rdi0”:0[1]’
    sudo media-ctl -d /dev/media0 -V ‘“imx214 3-001a”:0[fmt:SBGGR10/1920x1080],“msm_csiphy0”:0[fmt:SBGGR10/1920x1080],“msm_csid0”:0[fmt:SBGGR10/1920x1080],“msm_ispif0”:0[fmt:SBGGR10/1920x1080],“msm_vfe0_rdi0”:0[fmt:SBGGR10/1920x1080]’
    yavta -f SBGGR10P -s 1920x1080 -n 1 --capture=5 /dev/v4l/by-path/platform-a34000.camss-video-index0

Results:
When I execute the script I get absolutely no frame :frowning: Just thousands of irqs on a34000.camss_msm_csiphy0 (something like 1600 irqs/sec)

I have validated with a scope:
0) Power supplies

  1. Powerup sequence
  2. CSI clock
  3. CSI data (just the presence, my scope is not good fast enough for the data)

So I am very confident that there is some data flowing from the sensor.

I have also made some experiments using only 1 CSI lane on the DT and then I get some (corrupted) frames with random framerate and on some executions.

-Has anyone tried using 4 lanes CSI?
-Is there any documentation available for the csiphy and/or the camss?

Regards!


RAW10 Bayer format dump into memory
#2

Hi @ribalda

Actually you are trying a 4-lane sensor, MIPI uses the word channel for multiple sensors time multiplexed on the same lanes. The iMX214 has been tested on the 820c board and is known to work, however the software has evolved since the testing was done, and you have a unique board layout.

I would be VERY careful with the signal integrity of the MIPI lanes, You will need a 10+GHz scope to check that the signals are not corrupt. I assume that you followed the PCB layout rules in the 410 design guidelines and you did run simulations on your PCB layout and that they pass in simulation. (The design rules for MIPI-CSI lanes and clock are the same for both 410 and 820)

When you have 4 lanes you have a couple choices when connecting the camera lanes to the chip lanes. You always need to keep the P and N signals together, you can’t invert them (i.e. a P to N, and N to P swap) MIPI needs to keep the polarity. You can keep the lanes in order or you can reverse the lane order (i.e connect 0 to 3, 1 to 2, 2 to 1, and 3 to 0), you can also rotate the lane order (i.e 0 to 1, 1 to 2, 2 to 3, and 3 to 0) any number of steps of rotation, or rotation with the lanes in reverse order. These options are to allow you to optimize the PCB layout so you don’t have lane crossings. You cannot swap two lanes in the sequence (i.e 0 to 1, 1 to 0, 2 to 2 and 3 to 3), lanes must always be in ascending or descending order (with or without rotation).

Of course you need to tell the DeviceTree how you wired up the lanes. Looking at your changes one line looks strange to me data-lanes = <0 2 3 4>; , however I don’t remember the exact rules for the dts files and I think the clock is one of the 5 mipi lanes.

If you are using more than one lane on the MIPI-CSI bus, you need to inform the sensor to turn on the extra lanes, the driver should do this correctly based on your dtsi. MIPI lane 0 is actually bi-directional and initialization commands can flow from the host to the sensor on lane 0 during the startup phases.

-Lawrence-
Still looking for employment…


#3

Hi @ljking

Thanks for your response. The PCB routes the data lines in the “right order” (0 1 2 3). For setting the data-lanes on the DT I have used as inspiration the dual-channel ov5645 deffined at https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/tree/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi?h=release/qcomlt-4.14

				port {
					ov5645_2_ep: endpoint {
						clock-lanes = <1>;
						data-lanes = <0 2>;
						remote-endpoint = <&csiphy1_ep>;
					};
				};

But it could certainly be wrong.

I believe the phy is catching a problem with the data/clock/configuration/? , and this is why I am getting that big flow of IRQs. But with no documentation of the register of the camss I am clueless.

I have only seen the imx214 working on this board with Android, not with Linux and the drivers are quite different (v4l2 vs camera2).

Thanks!

PS: Thanks for the clarification of channels vs lanes :slight_smile: I have fixed the initial post