Hi,
I have a question about the NX GPIO’s pull-up. We have a custom board that has inputs that do not change state, unless there is an external pull-up added. The following is our setup for that pin:
spi2_cs0_pcc3 {
nvidia,pins = “spi2_cs0_pcc3”;
nvidia,function = “rsvd2”;
nvidia,pull = <TEGRA_PIN_PULL_UP>;
nvidia,tristate = <TEGRA_PIN_ENABLE>;
nvidia,enable-input = <TEGRA_PIN_ENABLE>;
nvidia,io-high-voltage = <TEGRA_PIN_DISABLE>;
nvidia,lpdr = <TEGRA_PIN_DISABLE>;
};
What is the strength of the pull-up? Is there anything else needed to be done (devicetree, software driver?) to ensure that the pull-up is enabled and functioning?
Malcolm
You want to enable this gpio as always up after system boots?
Hi
Yes. We want it to come up after boot as an input with an internal pull-up enabled.
Malcolm
Please refer to GPIO sysfs and see if you can toggle it as input first.
https://www.kernel.org/doc/Documentation/gpio/sysfs.txt
Hi,
Yes. I did that. It doesn’t work.
Here is the definition of the pin in our pinmux:
spi2_cs0_pcc3 {
nvidia,pins = “spi2_cs0_pcc3”;
nvidia,function = “rsvd2”;
nvidia,pull = <TEGRA_PIN_PULL_UP>;
nvidia,tristate = <TEGRA_PIN_ENABLE>;
nvidia,enable-input = <TEGRA_PIN_ENABLE>;
nvidia,io-high-voltage = <TEGRA_PIN_DISABLE>;
nvidia,lpdr = <TEGRA_PIN_DISABLE>;
};
I used the following command to extract the register as shown.
$ cat /sys/kernel/debug/tegra_pinctrl_reg and looked for SPI. This is what was displayed (sorry didn’t realize the capture was missing the first few character) but what is displayed is cut off is 0x0c302038
I cannot find a specific register definition in the reference manual for spi2, but did see that the padctrl register format as shown below. If this is the format of the register, then the pull-up is not initialized. Can you provide the register definition for this register?
Malcolm
Also, what is your method to update the pinmux?
We are using JetPack 4.x
Let me confirm with you what we did. We use /sys/class/gpio export the pin, this creates the pin in the /sys/class/gpio. Then we use the new definition to assign the direction and read the pin…
Is that what you are referring to?
We used the excel spreadsheet to define out pins and then create the .cfg files and add the pinmux to the device tree.
At least from a high level defintion.
And where did you use your cfg file…?
The cfg file is created, as per the instructions in the kernel/pinmux/t19x README, we copy the cfg files to bootloader/t186ref/BCT
The step sounds correct. Then the next question is are you sure the gpio # you give to export is really correct?
Yes. When we applied an external pull up resistor, the pin worked correctly using the above procedure and a scope. That lead us to question whether the internal pull up of that pin was correctly enabled. I did some probing and found the information from the register dump (sent to you back in our thread) that it looked like the pin was actually not initialized with a pull up.
Here is the excel file definition:
Its difficult to get it all uploaded. I hope you can read it
Hi,
Could you directly try to write the register with tool like devmem2 or devmem from busybox and see if this would enable the PU?
Hi,
I did write to the register 0x59 (pull up enabled) and when I read the register back it is 0x59.So the write works. However, when I then try to read the pin to see if the state is low or high it still always reads 0.
When I re-read the register value it is back to no pull-up.
Conclusion. I can write to register, set the pull-up, but after one read of the pin, the pull-up is disabled? All other bits are the same.
What would cause this?
Malcolm
Have you checked whether there is any other driver that is using this pin? Though I don’t think there would be. If there is, then gpio sysfs won’t let you export.
Could you also do test on other GPIO pin and see if they can detect the input 0/1?
Hi,
I can try some other GPIO. I have 2 other inputs, which I also think are also problem.
Can you confirm whether the line from the excel spreadsheet which I posted on Friday looks correct.
Also is the device tree assignment correct:
spi2_cs0_pcc3 {
nvidia,pins = “spi2_cs0_pcc3”;
nvidia,function = “rsvd2”;
nvidia,pull = <TEGRA_PIN_PULL_UP>;
nvidia,tristate = <TEGRA_PIN_ENABLE>;
nvidia,enable-input = <TEGRA_PIN_ENABLE>;
nvidia,io-high-voltage = <TEGRA_PIN_DISABLE>;
nvidia,lpdr = <TEGRA_PIN_DISABLE>;
};
What does “rsvd2” mean.
Is the command to read the register correct:
sudo cat /sys/kernel/debug/tegra_pinctrl_reg | grep spi2
This is what I read:
Bank: 1 Reg: 0x0c302038 Val: 0x00000052 → spi2_cs0_pcc3
Is there anything that doesn’t look correct. I just want to make sure the basic configuration is correct.
Malcolm
Also, Is this ok for the node definition of the pin:
nx_key_state {
gpio-hog;
input;
gpios = <TEGRA194_AON_GPIO(CC, 3) 0>; // x11 >;
label = “nx_key_state”;
status = “okay”;
};
Is gpio-hog ok for this?
Malcolm
