Camera tegracam_ctrl.c question

[user16748]

We are using L4T 35.4.1 on Orin AGX.

I see that in Nvidia source file tegracam_ctrls.c line 336, there is the section that bypassing certain gain and exposure transactions, and causing us seeing some failures in field. Basically due to AEC out of sync with actual sensor exposure settings in its registers.

	case TEGRA_CAMERA_CID_GAIN:
		if (*ctrl->p_new.p_s64 == ctrlprops->min_gain_val - 1)
			return 0;
		err = ops->set_gain(tc_dev, *ctrl->p_new.p_s64);
		break;
	case TEGRA_CAMERA_CID_FRAME_RATE:
		err = ops->set_frame_rate(tc_dev, *ctrl->p_new.p_s64);
		break;
	case TEGRA_CAMERA_CID_EXPOSURE:
		if (*ctrl->p_new.p_s64 == ctrlprops->min_exp_time.val - 1)
			return 0;
		err = ops->set_exposure(tc_dev, *ctrl->p_new.p_s64);
		break;

I want to know is there particular reason Nvidia wants to return 0 earlier on GAIN and EXPOSURE settings here?
We are looking for commenting out those so that each time transaction will happen, and don’t know if there are some regressions we should expect

[JerryChang]

hello user16748,

it’s a known issue as mentioned in… Release Notes (35.4.1).
you may workaround this failure by setting the min_gain_val/min_exp_time param sensors in device tree greater than 1 in linear scale.

FYI,
you should not see probing failure by moving to the latest rel-35 release version.
we also have some driver update in r35.5.0 to resolve such out of range failure.
for example,

diff --git a/drivers/media/platform/tegra/camera/tegracam_ctrls.c 
@@ -334,7 +334,7 @@ static int tegracam_set_ctrls(struct tegracam_ctrl_handler *handler,
        /* For controls that require sensor to be on */
        switch (ctrl->id) {
        case TEGRA_CAMERA_CID_GAIN:
-               if (*ctrl->p_new.p_s64 == ctrlprops->min_gain_val - 1)
+               if (*ctrl->p_new.p_s64 == ctrlprops->max_gain_val + 1)
                        return 0;
                err = ops->set_gain(tc_dev, *ctrl->p_new.p_s64);
                break;
@@ -342,7 +342,7 @@ static int tegracam_set_ctrls(struct tegracam_ctrl_handler *handler,
                err = ops->set_frame_rate(tc_dev, *ctrl->p_new.p_s64);
                break;
        case TEGRA_CAMERA_CID_EXPOSURE:
-               if (*ctrl->p_new.p_s64 == ctrlprops->min_exp_time.val - 1)
+               if (*ctrl->p_new.p_s64 == ctrlprops->max_exp_time.val + 1)

[user16748]

Thanks @JerryChang for quick response.
more questions

1. When you say “it’s a known issue” does it mean this added code is to resolve an “Known issue” or the added code introduced a known issue?

It seems the code added is related to alternate exposure feature. Then,
2. what if the alternate exposure feature is not available for our sensor, is it safe to just remove the

	if (*ctrl->p_new.p_s64 == ctrlprops->min_gain_val - 1)
		return 0;

and

		if (*ctrl->p_new.p_s64 == ctrlprops->min_exp_time.val - 1)
			return 0;

?

3. Also, one more question, what is alternate exposure? Is it something like HDR?
   Thanks in advance

[JerryChang]

hello user16748,

here’re two different approaches to resolve the failure…

1. that re-cap code is the code snippets from r35.5.0, you may apply the same kernel update to your driver.
2. you should revise your sensor device tree to configure the min_gain_val /min_exp_time param to be greater than 1 to workaround it.

@user16748

what is alternate exposure? Is it something like HDR?

it’s not like HDR.
it’s the added feature for certain sensors. (i.e. AR0234)
for instance, AR0234 having a hardware based automatic switching (exposure and analog gain) to capture frames,
this is a feature to support the alternate exposure and gain settings.

[user16748]

Thanks Jerry, that’s good info for now