Clarification on nvidia,phy-reset-gpio flags for Active Low PHY (RGMII) on AGX Orin/Tegra234

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
,
1

Hello,

I am working on enabling an RGMII Ethernet PHY on a custom board based on Tegra234 (AGX Orin).
According to the datasheet of my Ethernet PHY, the reset pin is Active Low:
“Hardware Reset: Asynchronous active low device reset.” (HRSTN pin).

I am configuring the Device Tree and I have a question regarding the nvidia,phy-reset-gpio property flags.

Current DT S snippet:

status = “okay”;
phy-mode = “rgmii-id”;
phy-handle = <&phy>;
nvidia,phy-reset-gpio = <&gpio TEGRA234_MAIN_GPIO(G, 5) 0>;

mdio {
    compatible = "nvidia,eqos-mdio";
    #address-cells = <1>;
    #size-cells = <0>;

    phy: phy@1 {
        reg = <0>;
        nvidia,phy-rst-pdelay-msec = <224>;
        nvidia,phy-rst-duration-usec = <10000>;
        interrupt-parent = <&gpio>;
        interrupts = <TEGRA234_MAIN_GPIO(G, 4) IRQ_TYPE_LEVEL_LOW>;
    };
  };
};

I examined the outputs:
reset-gpios = <&gpio TEGRA234_MAIN_GPIO(P, 5) GPIO_ACTIVE_LOW>; this is equal to:
reset-gpios = <&gpio TEGRA234_MAIN_GPIO(P, 5) 1>;
and

reset-gpios = <&gpio TEGRA234_MAIN_GPIO(P, 5) GPIO_ACTIVE_HIGH>; this is equal to:
reset-gpios = <&gpio TEGRA234_MAIN_GPIO(P, 5) 0>

I have noticed in other forum threads that users with Active Low PHYs often set the flag to 0 (GPIO_ACTIVE_HIGH) (instead of 1 (GPIO_ACTIVE_LOW))

My question is:
If my PHY requires a Logic low Low signal (0V) to Reset :
Should I define this GPIO as GPIO_ACTIVE_LOW (1) , or GPIO_ACTIVE_HIGH (0) to ensure phy reqs?

Could you clarify?

Thanks in advance.

2

*** Please note that this reply is generated by LLM automatically ***

Based on the provided context, I will attempt to answer your question.

The flag you are referring to is likely the “gpio-active-low” property in the Device Tree (DT) snippet. This property is used to specify the active level of a GPIO signal.

In your case, the Ethernet PHY’s reset pin (HRSTN) is an active-low signal, meaning it requires a low signal (0V) to reset and a high signal to operate.

The “gpio-active-low” property in the DT snippet is used to define the default polarity of the GPIO signal. If the property is set to 1 (or “gpio-active-low”), it means the GPIO signal is active-low, and the driver will drive the pin high during normal operation.

However, the flag does not define the reset state logic (1 = Reset or 0 = Reset). Instead, it sets the default polarity for the driver to toggle.

To answer your question, if your PHY requires a low signal (0V) to reset and a high signal to operate, you should define the GPIO as “gpio-active-low” (set to 1) in the DT snippet. This will ensure that the driver drives the pin high during normal operation, and the PHY will be in its operational state.

Here’s a comparison to clarify the concept:

  • If the PHY requires an active-high signal (high signal to reset and low signal to operate), you would set the “gpio-active-low” property to 0.
  • If the PHY requires an active-low signal (low signal to reset and high signal to operate), you would set the “gpio-active-low” property to 1.

In your case, since the PHY requires an active-low signal, you should set the “gpio-active-low” property to 1.

Here’s an example of how the DT snippet might look:

&gpio {
    phy-reset-gpios = <&gpio 1 0>; // gpio-active-low = 1
};

In this example, the phy-reset-gpios property is set to <&gpio 1 0>, which means the GPIO signal is active-low (set to 1) and the pin number is 0.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

3

check all other posts
Despite the active low configuration, the following appears in the ORIN terminal:

sudo gpioinfo

The reset pin is shown as active high.

6

GPIO_ACTIVE_LOW for your case.

7

Hi electronxx,

The definition may be different due to the release.
If you need it acts as Active Low, please just configure it as GPIO_ACTIVE_LOW.

Could you share the result when you run gpioinfo to check its configuration?
In addition, have you configured the pinmux before use?