Synchronization Issues on V4l2 Kernel V2 Driver


I am having an issue porting a sensor driver from V1 to V2 on JetPack-4.2.2.

My setup has 2 sensors that use an external trigger signal to synchronize streaming for both sensors. Sensor-1 uses extperiph1 clock and Sensor-2 extperiph2 clock from the TX2 and both are running at 24 Mhz.

If I run both sensors in continuous mode (not synchronized), both run at the correct framerate (30 fps). This works for V1 and V2.

If I run the sensors in slave mode (using an external signal to synchronize the framerate to 30fps) using V1 driver, the framerate is correct for both sensors (30fps) However, for V2 driver Sensor-2 runs at 30 fps, but Sensor-1 runs to 15 fps.

The sensor that receive extperiph1 clock (Sensor-1) is always running at 15fps when I try to capture from only one sensor at a time, but if I enable extperiph2 clock, sometimes I got 30fps from Sensor-1.
So, extperiph1 and extperiph2 are somehow dependent when using tegracam API.

I believe that there is a different clock handling when using tegracam API that is affecting the streaming when using the pulse synchronization.

I just wonder if anyone has this problem and if there’s a solution.


hello EnriqueR,

may I know what’s the major difference between your sensor driver V1 and V2.
you may check reference drivers, you’ll also found both extperiph1, and extperiph2 using clock source of PLLP_OUT0.
for example,

in addition,
may I know what’s the external signal to synchronize the frame.
is there’s a frame_sync pin for dual camera sensor synchronization.

Hi JerryChang,

I’m trying to have the minor possible changes between V1 and V2 implementation. Actually the device-tree is the same except for default and factor values are needed for v4l2 controls on V2.

I’m defining the clocks in the same way of that example:

clocks = <&tegra_car TEGRA186_CLK_EXTPERIPH1>,
	 <&tegra_car TEGRA186_CLK_PLLP_OUT0>;
clock-names = "extperiph1", "pllp_grtba";
mclk = "extperiph1";
clock-frequency = <24000000>;

clocks = <&tegra_car TEGRA186_CLK_EXTPERIPH2>,
	 <&tegra_car TEGRA186_CLK_PLLP_OUT0>;
clock-names = "extperiph2", "pllp_grtba";
mclk = "extperiph2";
clock-frequency = <24000000>;

To synchronize the sensors I’m configuring a PWM from the TX2. According to the framerate, the PWM period/duty-cycle is configured to allow streaming.
This works on V1 perfectly.

I’m not sure why I’m seeing these issues for V2, because for this version there are less things to configure in the driver and tegracam is doing the rest.

I believe that there is a kind of interference when enabling or configuring the experiph2 clock. Maybe when it is configured it’s not ready for capturing or it has a wrong frequency.


hello EnriqueR,

it’s hard to debug such clocking issue remotely,
could you please probe the MIPI signaling to check if any significantly difference.

Hi JerryChang,

I was able to solve the issue.

I did some testing analzying extperiph1 and extperiph2 clock signals using an oscilloscope and I got unstable wave forms (low amplitude and very noisy).

I found that power on/off sequences were not working good, because sometimes the communication with the sensors failed.

After some testing and debugging on reset and power-down gpios, I was able to solve those stability issues by removing the power-down gpio registration from the driver. The power-down gpio was not really needed in the driver because I keep the gpio state as constant value and I only change the state for the reset gpio, so I remove it.

I’m not sure why having defined the power-down gpio was causing me stability issues on power on/off, because I don’t change it state in the driver. I believe that there’s something that is done with this gpio when using tegracam implementation.

I don’t have issues on V1 if power-down gpio is registered on the driver, this issue only happens on V2.

After this change, I don’t have communications issues with the sensors and also I get the correct frame-rate for both sensors’ streaming.


hello EnriqueR,

we cannot reproduce the issue based-on JetPack-4.2.2 with reference multi-cam camera board.

please exclude PWDN gpio registration from your driver as your solutions,