Frame rate adjustment issues


We have a 12-bit RAW image sensor connected through CSI port on TX1 with L4T R28.1 version. We pull RAW images using v4l2 in C.

The sensor has both rolling shutter and global shutter modes. The global shutter capture is initiated by a signal to the TRIGGER pad.

When we use the rolling shutter, we adjust the frame rate by adjusting the frame length register of the sensor. However, the frame rate can only go to as low as 15 fps. If we set it lower, the measured frame rate is still 15 fps and there are dequeued frames that are empty (blank/black images). There are “frame start syncpt timeout!0” issues in the error log.

When we use the global shutter mode and trigger the sensor at 30 fps, the frame rate only reaches up to 7-8 fps. There are no errors in the log.

We changed the timeout setting in the vi2_fops.c file inside the tegra_channel_ec_init function.

chan->timeout = 20


chan->timeout = 80

This setting allowed the rolling shutter frame rate to go as low as 5 fps, while the global shutter mode improved slightly as it can now be triggered accurately up to 10 fps.

It seems that the timeout setting should have been adapting to the frame rate but it is a hard-coded value. I checked the R28.2 version and it is still hard-coded. Is there a patch to fix this csi/vi timeout issue or is there a specific setting that we should adjust as well?


hello luis.buno,

  1. may I have your confirmation that your use-case is launch camera sensor with low fps?
  2. please note that the unit of timeout setting is jiffies, 1 jiffy=10ms
  3. yes, you should adjust the timeout value. we don’t have a patch to adopt that with frame rate so far.

Hi JerryChang,

Thanks for responding.

  1. Use case for low fps is just for testing purposes. The low fps for rolling shutter mode might just be needed for as low as 10 fps. However, the main concern is bringing up the frame rate of the global shutter mode. Is there a frequency limit for the GPIO trigger?
  2. Yes, I considered this timeout unit in the settings that we tested.
  3. We’ll move forward with this adjusted timeout value then to solve the rolling shutter frame rate issue. But for the global shutter mode, is there a timeout/response time that we should adjust as well?

hello luis.buno,

you could control GPIO high/low in kernel drivers, may I have more details about what’s the “frequency limit” you mean for GPIO trigger.
FYI, we don’t fully support global shutter mode currently.

Hi JerryChang,

The frequency limit that I meant is the rate at which we can change/toggle the GPIO to high/low. Although, we already checked the trigger signal from TX1 GPIO and it does follow the expected frequency.

What changes have been done from R28.1 to R28.2 in terms of video buffer queuing/dequeuing?

I noticed that in R28.1, when triggering the global shutter at 30 fps, the frame rate is only at 10 fps but the frames are all good (no black/blank images).

However, in R28.2, while also triggering the global shutter at 30 fps, the frame rate reported is 30 fps but there are a lot of of black/blank frames.

Where is the function that controls buffer queuing/dequeuing in the L4T source files?

hello luis.buno,

you could refer to [L4T Release Notes] from to understand the improvements, bug fixes, branch difference…etc.

regarding to a lot of of black/blank frames,
could you please apply below change for testing. thanks

diff --git a/kernel/kernel-4.4/drivers/media/platform/tegra/camera/vi/vi2_fops.c b/kernel/kernel-4.4/drivers/media/platform/tegra/camera/vi/vi2_fops.c
index 4e02091..ce67712 100644
--- a/kernel/kernel-4.4/drivers/media/platform/tegra/camera/vi/vi2_fops.c
+++ b/kernel/kernel-4.4/drivers/media/platform/tegra/camera/vi/vi2_fops.c
@@ -383,6 +383,8 @@ static int tegra_channel_capture_frame(struct tegra_channel *chan,
 	int restart_version = 0;
 	bool is_streaming = atomic_read(&chan->is_streaming);
+	if(!is_streaming)
+		tegra_channel_ec_recover(chan);
 	/* Init registers related to each frames */
 	for (index = 0; index < valid_ports; index++) {