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

ribalda · September 12, 2018, 7:48pm

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

These are my steps so far:

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>;
    +				};
     			};
     		};
     	};

Created a driver for the module
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 Just thousands of irqs on a34000.camss_msm_csiphy0 (something like 1600 irqs/sec)

I have validated with a scope:
0) Power supplies

Powerup sequence
CSI clock
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!

ljking · September 12, 2018, 5:13pm

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…

ribalda · September 12, 2018, 7:48pm

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 apq8096-db820c.dtsi « qcom « dts « boot « arm64 « arch - working/qualcomm/kernel.git - Qualcomm Landing Team kernel

				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 I have fixed the initial post

chandong83 · July 26, 2019, 6:07pm

Hi @ribalda
I’m porting imx214 on the debian.
I wonder if you succeeded in this.

I want to know if it supports “mipi csi-2 bayer10bit” format.

I am using the following link source.
http://releases.linaro.org/96boards/dragonboard410c/linaro/debian/latest/

Please Give me a little hint.
Thank you.

ribalda · July 30, 2019, 12:00pm

Hi @chandong83, I have already upstreamed the driver:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/i2c/imx214.c

chandong83 · July 30, 2019, 12:23pm

Hi @ribalda, Thank you for your reply.
I have a question.
Do you also get the Camera Data to RDI(Raw Dump Interface) instead of PIX?
Thank you.

ribalda · July 30, 2019, 2:10pm

I wish I could use the PIX :), It is RDI only.

DO you have some driver that has support for PIX in bayer mode?

chandong83 · July 30, 2019, 2:16pm

@ribalda
No, i don’t have it.
I think I should use RDI too.
Thank you.

kimbo · August 20, 2019, 9:58pm

Hi Ribalda,

Were the data-lanes <0 2 3 4> for endpoint and <0 1 2 3> for camss correct? I ask because I am also trying to get 4 data lane capture working but with an imx412 sensor on a custom board with a snapdragon 820 chip. I can capture something but it’s not correct.

thanks,
Kim

ljking · August 21, 2019, 1:38am

It really depends on the design of your custom board. The idea is to have the board laid out in such a way as to not have the MIPI-CSI lines crossing each other (causes interference). There are many possible ways you can program the data lanes, with a couple caveats: not every permutation is possible, and it needs to match your board layout. I know I wrote detailed documentation for this before I left Qualcomm, but I am uncertain if it as ever published.

kimbo · August 21, 2019, 4:13pm

Hi ljking,
Thanks for the response! Per documentation I’ve read, the lanes (clock and data) should be the physical lanes, correct? Per the pinout on the SOM from Inforce that I am using, the data-lanes for the endpoint seem correct. It looks like clock is on lane 1 and data lanes are 0,2,3, and 4. How are the clock-lanes and data-lanes in the camss mapping to the endpoint lanes? It looks like in the device-tree from Inforce it shows this for the camera endpoint:
port@0 {
ov5640_ep: endpoint {
clock-lanes = <1>;
data-lanes = <0 2>;
remote-endpoint = <&csiphy0_ep>;
};
};
and for camss:
csiphy0_ep: endpoint@1 {
clock-lanes = <7>;
data-lanes = <0 1>;
remote-endpoint = <&ov5640_ep>;
//status = “disabled”;
};
Why are the clock-lanes and data-lanes different in the above? What does 7 mean for a clock-lane?

Thanks,
Kim

ljking · August 21, 2019, 11:39pm

MIPI-CSI data receivers and clock receivers are exactly the same inside the chip, so that they have the same delay in all conditions.
Hence any one of the 5 receivers could be the clock receiver. The <7> looks wrong to me, but it could have special meaning in the driver.

The data lanes can be rotated or flipped, but not crossed Example rotations 0234, or 2340, or 3402, or 4023 and example flip 0234, or 4320.

You can use 1,2,3 or 4 lanes, depends on your camera and desired data rates.

I’m not sure about the mapping into the camss, I am a hardware guy, just worried about getting the camera correctly connected to the chip. I am pretty sure I wrote a chapter in the 410 design guidelines, the MIPI-CSI layout guidelines apply to the 820.

Speaking of which, MIPI-CSI signals are VERY sensitive to the board layout, have you simulated the signal integrity on your boards? If you are dropping bits, or have one lane arriving 300pS late, no matter how much you play with the software it is not going to work.

Most 4-lane cameras will work in 1,2,3 or 4-lane modes, try forcing single lane at a low bit rate and frame rate to test basic operation before going for full speed.

You can’t look at MIPI-CSI signals with an oscilloscope, simply attaching the scope usually creates too much impedance discontinuity. That’s why you simulated PCB layout.

Since you are using an InForce board, maybe they will help you.

kimbo · August 22, 2019, 8:05pm

Hi ljking,
Thank you for the detailed explanation. A hardware guy here is going to double check the board layout and verify with simulation.
On the software side, I think it could possibly be a driver issue. The vendor, for the camera, gave me a driver that should work with either 2 or 4 lanes, but only 2 lanes works correctly. It is possible the driver was never tested so I’m waiting to hear back from them.

I will let you know if I find a solution!
Thanks,
Kim