Toggle the ethernet/Phy power supply on Verdin

Hi All,

Is there a way to toggle the power supply to for Ethernet module/Phy on the Verdin IMX8M-Mini module?

I noticed there is a pin PMIC_EN_ETH in the dtsi file for verdin imx8mm-verdin-v1.1.dtsi « freescale « dts « boot « arm64 « arch - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules
Can this be used to toggle the power to the ethernet? If yes, can someone please give details on how to achieve this?

Regards,
Gaurav

Greetings @gauravks,

You’re on the right track, that pin controls the voltage rail/regulator for the Ethernet phy. For the hardware details about this pin you can check out the bottom of page 30/ top of page 31 of the Verdin i.MX8MM datasheet.

As for the device tree details. So the voltage regulator for the Ethernet phy is described here: imx8mm-verdin-v1.1.dtsi « freescale « dts « boot « arm64 « arch - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules

It uses a standard regulator syntax definition from the kernel. You can see the syntax in these two files: https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/fixed-regulator.txt & https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/regulator.yaml

Now the tricky part is toggling the power. Just to clarify it sounds like you want to be able to toggle the power state from userspace?

If so this might be a bit problematic. In my research, it doesn’t seem very typical for Linux to allow manipulation of regulators from userspace. Not to say it’s impossible but it doesn’t seem to be the most well-supported operation.

I did find the following blog: https://www.studiofuga.com/2019/07/18/adding-a-user-space-power-switch-to-your-embedded-linux/

Which suggests that with the following driver: linux/userspace-consumer.c at master · torvalds/linux · GitHub

It would be possible to manipulate voltage regulators from user space. Though I have not tested this method so I can’t really vouch for it.

Now with all that information given. Perhaps let’s start simple first.

What is your exact use-case here?

It sounds like you want to be able to toggle the ethernet PHY on/off from Linux userspace. Is that correct? Also why do you want to do this?

Perhaps we can find an alternative solution depending on your use-case here.

Best Regards,
Jeremias

Hi Jermias,

Thanks for the detailed response and my apologies for late response.

Yes the use-case is to control the PHY power from the user space application to avoid certain EMC related issues which we have been facing.

@edwaugh Can you please give more details on the use-case.

Regards,
Gaurav

HI @jeremias.tx,
We are working with @matthias.tx on this problem. In our testing we see a large amount of radiated emissions from the PHY on the Verdin board. This is affecting our modem receive performance and is preventing us from passing the required regulatory tests.
We need to be able to test the system fully running with and without the PHY powered to be certain. Do be able to dynamically change this would be preferable. If we have to do it with a device tree change and reflash the device every time we could but that will be much more difficult for our contractors.
Thanks very much
Ed

Thank you for the explanation I believe I understand your situation now. Due to these EMC tests you truly do you require the PHY to be powered off fully.

This should be possible, the only complex bit would be doing this dynamically from user-space. Allow me some time to to check and consult internally and see what is possible here.

Best Regards,
Jeremias

Alright I think I got a solution for you here. You’ll still need to make a device tree change but it will allow you to change the power state of the ethernet PHY during runtime from userspace, without switching images.

In short you need to remove the ethernet voltage regulator reference in the device tree I referenced earlier. Then configure the PMIC_EN_ETH pin as a free GPIO. What this does is allow you, the user, to modify the value of this pin from userspace. Physically the pin is still connected to the power circuit for the ethernet PHY, so changing it’s value will still affect the power state.

However keep in mind that by removing the reference to the regulator in the device tree this means the pin isn’t being managed by the kernel or any software drivers. In other words this may lead to unforeseen behavior.

Here’s a reference of the device tree changes:

diff --git a/dts-arm64/imx8mm-verdin.dtsi b/dts-arm64/imx8mm-verdin.dtsi
index c7c0722..9dfe401 100755
--- a/dts-arm64/imx8mm-verdin.dtsi
+++ b/dts-arm64/imx8mm-verdin.dtsi
@@ -75,20 +75,6 @@
                regulator-name = "REG_MIPI_PHY";
        };
 
-       reg_ethphy: regulator-ethphy {
-               compatible = "regulator-fixed";
-               enable-active-high;
-               gpio = <&gpio2 20 GPIO_ACTIVE_HIGH>; /* PMIC_EN_ETH */
-               off-on-delay = <500000>;
-               pinctrl-names = "default";
-               pinctrl-0 = <&pinctrl_reg_eth>;
-               regulator-boot-on;
-               regulator-max-microvolt = <3300000>;
-               regulator-min-microvolt = <3300000>;
-               regulator-name = "V3.3_ETH";
-               startup-delay-us = <200000>;
-       };
-
        reg_usb_otg1_vbus: regulator-usb-otg1 {
                compatible = "regulator-fixed";
                enable-active-high;
@@ -201,7 +187,6 @@
        fsl,magic-packet;
        phy-handle = <&ethphy0>;
        phy-mode = "rgmii-id";
-       phy-supply = <&reg_ethphy>;
        pinctrl-names = "default", "sleep";
        pinctrl-0 = <&pinctrl_fec1>;
        pinctrl-1 = <&pinctrl_fec1_sleep>;
@@ -806,7 +791,7 @@
                    <&pinctrl_gpio3>, <&pinctrl_gpio4>,
                    <&pinctrl_gpio7>, <&pinctrl_gpio8>,
                    <&pinctrl_gpio_hog1>, <&pinctrl_gpio_hog2>, <&pinctrl_gpio_hog3>,
-                   <&pinctrl_pmic_tpm_ena>;
+                   <&pinctrl_pmic_tpm_ena>, <&pinctrl_reg_eth>;
 
        pinctrl_can1_int: can1intgrp {
                fsl,pins = <

You can then use whatever method to manipulate the GPIO from user-space. In my short tests when I set the GPIO to low, I lose all ethernet functionality and I can see the LEDs on the Ethernet port turn off. Which seems to be a pretty good indication that power was cut off.

Best Regards,
Jeremias

1 Like

Hi @jeremias.tx,

Thanks for spending time to find out this solution.

I tested this on the board and I can use the GPIO to control the phy and see that the LEDs turn off when I change the values.

Although I do see an issue with the regular operation. I notice that even though the PHY is switched by default the Ethernet Interface is unable to acquire any IP address. I tried manually invoking the dhclient but it didn’t succeed either.

Can you please confirm if you have the same behavior on your board as well?

Regards,
Gaurav

I did some more debugging and the Ethernet device required a powercycle or reinitialization as well

I used ifconfig eth down followed by ifconfig eth up which makes the ethernet interface get the IP address correctly.

Thanks for the support in finding the solution

Glad we were able to work something out here. Also yes you’ll need to be careful from here on out since the ethernet PHY power isn’t being automatically managed by the kernel anymore.

I haven’t tested this solution long term so there may be some unforeseen issues later down the road.

Best Regards,
Jeremias

Hi @jeremias.tx
we are repeating these EMC tests on our latest devices. I have made the changes to the device tree and I’m able to control the phy, but I end up having the same issue as Gaurav, where the IP address is not acquired. his solution of bring up down and up the interface with ifconfig doesn’t seem to work. any suggestions?

Hi @RoccoBr,

I just re-tested this old solution on my setup running Torizon 5.7.2. It seems to still work for me at least. When I toggle the PHY via manual GPIO control the IP address is lost upon re-enabling the PHY. But, the ifconfig trick from Gaurav works for me to restore the IP address.

I’m not sure if your setup differs or this depends on the connected Ethernet device or something else. I’m just using a standard Toradex setup with our standard carrier board.

Best Regards,
Jeremias