Upgrading from TX2 to TX2-4G results in nonfunctional GPIO


We have recently transitioned from a Jetson TX2 where cat /etc/nv_tegra_release is as follows (we’ll call this the “old” system):

R28 (release), REVISION: 2.1, GCID: 11272647, BOARD: t186ref, EABI: aarch64, DATE: Thu May 17 07:29:06 UTC 2018

to a Jetson TX2 4 GB where cat /etc/nv_tegra_release is this (we’ll call this the “new” system):

R32 (release), REVISION: 2.1, GCID: 16294929, BOARD: t186ref, EABI: aarch64, DATE: Tue Aug 13 04:45:36 UTC 2019

We are trying to read from GPIO gpio_pq4_pi4 in a kernel module. We request an interrupt line using request_irq(..., IRQF_TRIGGER_RISING, ...).

In the “old” system this works flawlessly, but in the new system we appear to not be receiving the interrupt. Instead we see lines like this in the kernel log:
gpio tegra-gpio wake63 for gpio=68(I:4)

Can someone please help us understand what we need to change on the “new” system so that we can receive interrupts on this GPIO? Do we need to change how we request the interrupt? Do we need to rebuild the system so as to disable wake63 somehow? Something else?

Thank you in advance!

hello user154224,

you may modify device tree by settings it as an interrupt.
for example,

                interrupt-parent = <&tegra_main_gpio>;
                interrupts = <TEGRA_MAIN_GPIO(I, 4) 0x01>;

Thanks for the quick reply. I have a few follow-up questions to clarify.

I’m assuming when you mention modifying the device tree of the TX2, you’re referring to the process outlined in this documentation: TX2 Pinmux Configuration Process.

With respect to the code snipped you posted:

is this to be copy/pasted into one of those .dtsi files outlined in the documentation above? I ask because the next step of the documentation linked above requires two of these .dtsi files in order to complete. I’ve linked it here: Generating Configuration files using dts2cfg. In the documentation, those .dtsi files are called PINMUX_DTS_FILE, and GPIO_DTS_FILE, respectively. Which one of these files should the above code snippet be copy/pasted into? Or should it be inserted somewhere else?

Also, the result of running pinmux-dts2cfg.py is expected to be a .cfg file. My current understanding of the flashing process is that this .cfg file needs to be placed in the Linux_for_Tegra/bootloader/t186ref/BCT/ directory before flashing the device. Is that accurate? I’ve taken a look at my current .cfg file, which has entries in this format:

pinmux.<address> = <value>; # comment describing name of pin and settings

I’m having trouble parsing the meaning of <value> in the above format - is there documentation somewhere explaining what these bit flags mean?

Again, I appreciate your assistance in this matter.

hello user154224,

there’re two ways to alter the pin configuration, pinmux and device tree.
pinmux is using the *.cfg file, which used by the bootloader stage to init the pin settings. while the kernel boot-up, it loads the device tree to overwrite the settings.
you could only change the device tree if you’ve pin with the same usage as the default pin define, such as GPIO; on the other hand, please update the pinmux if you’re going to toggle it as SFIO.

please access Jetson Linux | NVIDIA Developer to download the L4T Driver Package (BSP) Sources, you should extract kernel_src.tbz2 to obtain device tree sources for customization, following the Kernel Customization chapter the build the customize *.dtb file.
you could disassembler the dtb file into text file for modification, i.e. $ dtc -I dtb -O dts -o modify.dts tegra.dtb
please note that’s using hex to specify the property values, once you complete the modification, you could convert the DTS into a new DTB to update your board, i.e. $ dtc -I dts -O dtb -o new-tegra.dtb modify.dts

Thanks for the assistance with this issue. I wanted to let you (and posterity) know that we’ve resolved the behavior described in the first post, and it ended up not being related to the pinmux settings on the board at all.

In particular, the issue seems to have stemmed from our usage of request_irq(...) as opposed to its threaded cousin, request_threaded_irq(...). Switching to the threaded version, along with eliminating a call to gpio_set_debounce(...) allowed us to start receiving signals on the allocated interrupt line. It’s worth noting that many different timings were tried for gpio_set_debounce, and only getting rid of the call entirely seemed to work.

I’m still not sure why the behavior on the TX2-4G changed without a deprecation warning in the case of request_irq(...) if an explicit change was made, but at this point I’m just happy there’s a solve in place and hopefully this information will be of some use to someone in the future if they’re experiencing the same problem.

hello user154224,

thanks for sharing, so you were only modify your drivers.
is there any particular kernel-4.9 changes to make it works?

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.