We are attempting to use PEE.02 (pin #212) as an interrupt pin for SPI communication, but it seems there are issues with our driver claiming this pin and seeing the interrupt signals. When we switch to a different GPIO (PQ.06, pin #216) for our interrupt, communication works as intended. Is PEE.02 reserved for something other than a general-purpose GPIO? I see in the pinmux dtsi that it is called out as “ao_retention_n”, as opposed to “soc_gpio.” What does this mean?
1 Like
Hi graceagrace,
Are you using the devkit or custom board for Orin NX?
What’s your Jetpack version in use?
PEE.02 is from AON(Always On) GPIO controller.
What do you mean about the issue when your driver requests this pin?
Is there any error in dmesg?
We are using a custom carrier board with Jetpack 5.1.3 installed. There are no errors in dmesg, and like I mentioned, SPI functions as expected when using a different GPIO.
In our SPI setup, the Jetson is the master, and our microcontroller is the slave. The behavior we see when trying to use PEE.02 as the interrupt pin is that the Jetson does not acknowledge that there is data to receive, essentially “ignoring” the interrupt and ceasing communication, despite both devices being online. I am wondering if there is a Jetson hardware-related reason why we are encountering this problem with PEE.02 but not with PQ.06.
Please share the device tree how you configure PEE.02 as interrupt.
We are using libgpiod to poll the interrupt and are not using a device tree configuration. We use the method gpiod_line_event_wait(), as described here. When I use gpio get on the command line, I am able to see the state of PEE.02; however, Linux does not register events on this pin in a way that we can use libgpiod.
Additionally, I did try to configure PEE.02 as an interrupt in the device tree, but this did not work, either. Below is my configuration for the SPI device:
spi@0 {
compatible = "tegra-spidev";
reg = <0x00>;
spi-max-frequency = <0x2faf080>;
interrupt-parent = <0x51>;
interrupts = <0x155 0x02>;
nvidia,polling-mode;
controller-data {
nvidia,cs-setup-clk-count = <0x20>;
nvidia,rx-clk-tap-delay = <0x10>;
nvidia,tx-clk-tap-delay = <0x0f>;
};
};
The interrupt-parent is the phandle for the tegra_aon_gpio controller.
I would like to check the one from source of device tree rather than the one decompiled from dtb.
Maybe you should use TEGRA234_AON_GPIO instead of TEGRA_AON_GPIO.
I don’t understand what you mean by “source of device tree.” Do you mean the pinmux .dts?
The appropriate phandle reference is tegra_aon_gpio, which is what interrupt-parent refers to. What you said would be possible when referencing the GPIO itself as part of interrupts, but I am using the pin number instead.
All of this is irrelevant to my question of what the significance PEE.02 being called out as “ao_retention_n” is. I am asking if this pin is reserved for anything by the Jetson SoM which could be preventing us from correctly polling it as an interrupt GPIO.
The device tree you provided are all hex value so that I don’t know what they mean.
I want to check the device tree from the source(you can refer to Kernel Customization — NVIDIA Jetson Linux Developer Guide 1 documentation to get the source and check the device tree files)
Currently, I don’t find other drivers using this pin and it seems configured as input pin in pinmux by default.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.