BUG : Declaring TEGRA_MAIN_GPIO(R, 0) aka qspi_sck_pr0 as GPIO in the DT makes it stop working

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

Hello,

For completeness reason, I have added this gpio description in my DT, as follows :

        gpio@2200000 {
            cam0_pwdn {
                    gpio-hog;
                    gpios =  <TEGRA_MAIN_GPIO(R, 0) 0>;
                    output-low;
            };
       };

But when I do that, my GPIO stops to work.

I tracked it down with
sudo cat /sys/kernel/debug/tegra_pinctrl_reg | grep “qspi_sck_pr0”
and discovered that
Bank: 0 Reg: 0x0243b020 Val: 0x00000401 → qspi_sck_pr0
was replaced by
Bank: 0 Reg: 0x0243b020 Val: 0x00000001 → qspi_sck_pr0

Note the disparition of the 0x400 bit, which is the GPIO bit.

Looking in the code I found the culprit in the kernel-4.9 tree, in the file drivers/pinctrl/tegra/pinctrl-tegra.c, in the function ‘tegra_pinctrl_gpio_set_direction’, where we see :

    if (pmx->soc->is_gpio_reg_support)
            ret = tegra_pinconfig_group_set(pctldev, group,
                                    TEGRA_PINCONF_PARAM_GPIO_MODE, 0);

Those lines merely remove the GPIO bit, although we are in a function working with GPIO’s.

Commenting out those lines makes the GPIO work again, but why are they there in the first place ? The job of a function called ‘tegra_pinctrl_gpio_set_direction’ is only to set the direction bit(s), not to touch the GPIO bit, and certainly not to disable it.

Do you have a better fix than simply turning off the culprit statements ?

Thanks in advance

3

hello phdm,

may I know which JetPack release you’re working with,
do you have pinmux customization to update the board configuration? it seems this pin is default configured as GPIO0/CAM0_PWR# / GPIO3_PR.00.

4

jetpack 4.3

Yes, it works perfectly in its default state, but I had problems with TEGRA_MAIN_GPIO(R,5) aka qspi_cs_n_pr5, that I solved by adding the following lines in my DT :

    gpio@2200000 {
            cam0_rst {
                    gpio-hog;
                    gpios = <TEGRA_MAIN_GPIO(R, 5) 0>;
                    output-low;
            };
    };

For completeness resaon, I then tried to do the same for R,0, but doing that breaks R,0 :(

8

Hi phdm,
R,5 is used for cam_rst but R,0 is for power down. how are you verifying that gpio R,0 is not working?

9

After adding the cam0_pwdn description, my sensor did not answer at all anymore on it’s SPI bus, with R,0 set either to 1 or to 0. Removing that description made my sensor answer again.

12

Can you read this register 0x0243b020 in working state?
You can use devmem to read.

13

Here you are :

root@cam5-lego:~# sudo cat /sys/kernel/debug/tegra_pinctrl_reg | grep 0x0243b020
Bank: 0 Reg: 0x0243b020 Val: 0x00000001 → qspi_sck_pr0
root@cam5-lego:~#

14

Hi phdm,
For your information, Reg: 0x0243b020 Val: 0x00000001 means the pin is made GPIO and is expected since you have added it under gpio.
If 10th bit is set means it’s not GPIO configured, it’s being used. Are you using camera?

16

Soory for the noise. Finally the problem seemed related to the problem mentionned in my other post https://forums.developer.nvidia.com/t/problem-with-usage-of-pwdn-gpios-in-sensor-drivers/175914