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

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

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.

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 :(

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?

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.