Camera Power Down GPIO usage issue

[t_msg]

I tried to add an IMX477 camera on AGX Orin, but encountered a GPIO busy problem (gpio_request failed).

By checking /sys/kernel/debug/gpio, I found that the GPIO was occupied by camera-control-output.

I found the definitions related to camera-control-output in the device tree, but I commented them out. The related gpio in /sys/kernel/debug/gpio was still occupied by camera-control-output.

Finally, I tried not to load dtbo. Strangely, the related gpio was still occupied.
What is the reason?

extlinu.conf:

dtb:
tegra234-p3737-0000+p3701-0000-nv.zip (41.6 KB)

[JerryChang]

hello t_msg,

FYI,
there’re two pdwn pins defined by default.
for instance,
#define CAM0_PWDN TEGRA234_MAIN_GPIO(H, 6)
#define CAM1_PWDN TEGRA234_MAIN_GPIO(AC, 0)

[t_msg]

Hi JerryChange,
What does defined by default mean?
Does it mean that they are defined by default in the device tree, or that the driver will occupy them by default?

Also the GPIO I am using is the same as the one you gave.

[JerryChang]

hello t_msg,

I meant you should have below in your sensor device tree to utilize the pin,
pwdn-gpios = <&gpio CAM0_PWDN GPIO_ACTIVE_HIGH>;

[t_msg]

This is exactly what I’m doing, but the driver complains about gpio_request failing.

[JerryChang]

hello t_msg,

please add some debug prints,
you should parse the reset pin here correctly, right?

static struct camera_common_pdata *imx477_parse_dt(...)
{
...
        gpio = of_get_named_gpio(np, "reset-gpios", 0);
        board_priv_pdata->reset_gpio = (unsigned int)gpio;

if that’s correct, you may simply set pw->reset_gpio = pdata->reset_gpio;.
after that, using gpio_set_value(pw->reset_gpio, 1 or 0); to toggle pin high/low for sensor power-on/off function.

[t_msg]

Yes, in fact i did not modify the nv_imx477 driver.
The only difference between it and what you said is the addition of gpio_request.

[JerryChang]

hello t_msg,

you may add gpio_is_valid() to check the pin, toggle the pin only when the pin is available.
or.. please try below code snippets for the bring-up stage.

@@ -522,14 +522,6 @@ static int imx477_power_get(struct tegracam_device *tc_dev)
 
        /* Reset or ENABLE GPIO */
        pw->reset_gpio = pdata->reset_gpio;
-       err = gpio_request(pw->reset_gpio, "cam_reset_gpio");
-       if (err < 0) {
-               dev_err(dev, "%s: unable to request reset_gpio (%d)\n",
-                       __func__, err);
-               goto done;
-       }
-
-done:
        pw->state = SWITCH_OFF;

[t_msg]

Yes, now I’ve tried commenting out gpio_request when testing.
But I’d like to understand why this is happening.
I can’t understand why these GPIOs are still occupied when no one in the device tree has declared that they need to be used.

[JerryChang]

hello t_msg,

let’s try using gpio_is_valid to check this reset_gpio pin before calling gpio_request.
for instance,

if (gpio_is_valid(pw->reset_gpio)) {
    ret = gpio_request(pw->reset_gpio, "cam_reset_gpio");
...

[t_msg]

Same results:

[JerryChang]

hello t_msg,

just wondering why the error return -16 in the logs.
per header file, the return error should be.. #define EPROBE_DEFER 517 /* Driver requests probe retry */
anyways, are you able to bring-up your camera following the workarounds in comment #9?

[t_msg]

I need to directly pull up the camera’s poweren on the hardware, otherwise it won’t start.

[JerryChang]

it seems like a pin did not configured correctly, may I know which Jetpack release version you’re working with.

[t_msg]

JetPack6.2, L4T36.4.3

[JerryChang]

hello t_msg,

please also refer to IMX274, which is verified on AGX Orin/JP-6.2/r36.4.3

[t_msg]

I checked the kernel code and device tree of IMX274, but I don’t see anything special.
Also, is there any explanation for “GPIO is not referenced in the device tree but is still occupied in /sys/kernel/debug/gpio”?
I think if I figure it out, the problem should be solved.

[t_msg]

In addition, I also tested that the unused GPIOs shown in /sys/kernel/debug/gpio can be correctly requested by gpio_request

[JerryChang]

hello t_msg,

you may ignore that gpio_request failure,
I’ve tested locally with IMX185 on AGX Orin.
I’m still able to fetch the frame although it’s reported unable to request reset_gpio.
for instance,

[   10.201011] imx185 9-001a: probing v4l2 sensor
[   10.201105] imx185 9-001a: imx185_power_get: unable to request reset_gpio (-16)
[   10.201188] imx185 9-001a: tegracam sensor driver:imx185_v2.0.6
[   10.205400] tegra-camrtc-capture-vi tegra-capture-vi: subdev imx185 9-001a bound
[   10.223851] imx185 9-001a: Detected IMX185 sensor

$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG12 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=10
<<<<<<<<<<

$ gst-launch-1.0 nvarguscamerasrc sensor-id=0 sensor-mode=0 ! 'video/x-raw(memory:NVMM),width=1920, height=1080, framerate=30/1, format=NV12' ! nvvidconv ! fpsdisplaysink text-overlay=0 name=sink_0 video-sink=fakesink sync=0 -v
...
/GstPipeline:pipeline0/GstFPSDisplaySink:sink_0: last-message = rendered: 17, dropped: 0, current: 33.89, average: 33.89
/GstPipeline:pipeline0/GstFPSDisplaySink:sink_0: last-message = rendered: 33, dropped: 0, current: 30.25, average: 32.02
/GstPipeline:pipeline0/GstFPSDisplaySink:sink_0: last-message = rendered: 49, dropped: 0, current: 30.26, average: 31.43

may I also know which Jetpack release version you’re working with?
could you please try to bring-up single camera first to ensure which GPIO pin you cannot toggle now?

[t_msg]

Hi JerryChange,

you may ignore that gpio_request failure,
I’ve tested locally with IMX185 on AGX Orin.
I’m still able to fetch the frame although it’s reported unable to request reset_gpio.
for instance,

I think I understand what you mean, but this doesn’t seem to be a “standard” process.
Can’t find out the specific reason now?

may I also know which Jetpack release version you’re working with?
could you please try to bring-up single camera first to ensure which GPIO pin you cannot toggle now?

As I mentioned above, I’m using JetPack6.2, L4T36.4.3. And I did add only a single camera to the device tree.