[PATCH v2 4/4] arm64: dts: freescale: Add DEBIX SOM A and SOM A I/O Board support

[Marco Felsch]

Hi Laurent,

On 23-07-25, Laurent Pinchart wrote:
> Hi Marco,
> 
> Thank you for the patch.
> 
> On Mon, Jul 17, 2023 at 06:51:27PM +0200, Marco Felsch wrote:

...

> > +	reg_baseboard_vdd3v3: regulator-baseboard-vdd3v3 {
> > +		compatible = "regulator-fixed";
> > +		regulator-min-microvolt = <3300000>;
> > +		regulator-max-microvolt = <3300000>;
> > +		regulator-name = "BB_VDD3V3";
> > +		gpio = <&expander0 10 GPIO_ACTIVE_HIGH>;
> > +		/* Required timings for ethernet phy's */
> > +		startup-delay-us = <50000>;
> 
> The regulator's datasheet shows a much smaller delay (about 1500µs with
> a 3A load).
> 
> > +		off-on-delay-us = <110000>;
> 
> Is this really a property of the regulator ? Or a requirement of the
> ethernet PHY ? In the latter case, shouldn't it be handled by the PHY ?

As written in the above comment: the delays are required by the PHYs.

> > +		enable-active-high;
> > +		regulator-always-on;
> 
> Why always on ? Same for the other supplies.

I don't have the SoM schematics and I wanted to keep it simple while
porting the downstream DTS. For this regulator we can drop the
'regulator-alaways-on' property but for the others I rather tend to keep
it. As this is an EVK this board should never made it into real products
and so power-consumption/optimization isn't really important.

> > +	};
> > +
> > +	reg_baseboard_vdd5v0: regulator-baseboard-vdd5v0 {
> > +		compatible = "regulator-fixed";
> > +		regulator-min-microvolt = <5000000>;
> > +		regulator-max-microvolt = <5000000>;
> > +		regulator-name = "BB_VDD5V";
> > +		gpio = <&expander0 9 GPIO_ACTIVE_HIGH>;
> > +		enable-active-high;
> > +	};
> > +
> > +	regulator-som-vdd1v8 {
> > +		compatible = "regulator-fixed";
> > +		regulator-min-microvolt = <1800000>;
> > +		regulator-max-microvolt = <1800000>;
> > +		regulator-name = "SOM_VDD1V8_SW";
> > +		gpio = <&expander0 12 GPIO_ACTIVE_HIGH>;
> > +		enable-active-high;
> > +		regulator-always-on;
> > +	};
> > +
> > +	regulator-som-vdd3v3 {
> > +		compatible = "regulator-fixed";
> > +		regulator-min-microvolt = <3300000>;
> > +		regulator-max-microvolt = <3300000>;
> > +		regulator-name = "SOM_VDD3V3_SW";
> > +		gpio = <&expander0 11 GPIO_ACTIVE_HIGH>;
> > +		enable-active-high;
> > +		regulator-always-on;
> > +	};
> > +
> > +	reg_usdhc2_vmmc: regulator-usdhc2 {
> > +		compatible = "regulator-fixed";
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
> > +		regulator-name = "VSD_3V3";
> 
> This seems to be produced by the SoM, it should be moved to the SoM
> .dtsi.

You're right, albeit the arrow is pointing to J6. I'll fix this.

> > +		regulator-min-microvolt = <3300000>;
> > +		regulator-max-microvolt = <3300000>;
> > +		gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
> > +		enable-active-high;
> > +	};
> > +
> > +	regulator-vbus-usb20 {
> > +		compatible = "regulator-fixed";
> > +		regulator-min-microvolt = <5000000>;
> > +		regulator-max-microvolt = <5000000>;
> > +		regulator-name = "USB20_5V";
> > +		gpio = <&expander1 14 GPIO_ACTIVE_HIGH>;
> > +		enable-active-high;
> > +		regulator-always-on;
> > +		vin-supply = <&reg_baseboard_vdd5v0>;
> > +	};
> > +
> > +	regulator-vbus-usb30 {
> > +		compatible = "regulator-fixed";
> > +		regulator-min-microvolt = <5000000>;
> > +		regulator-max-microvolt = <5000000>;
> > +		regulator-name = "USB30_5V";
> > +		gpio = <&expander1 12 GPIO_ACTIVE_HIGH>;
> > +		enable-active-high;
> > +		regulator-always-on;
> > +		vin-supply = <&reg_baseboard_vdd5v0>;
> > +	};
> > +
> > +	reg_vdd5v0: regulator-vdd5v0 {
> > +		compatible = "regulator-fixed";
> > +		regulator-min-microvolt = <5000000>;
> > +		regulator-max-microvolt = <5000000>;
> > +		regulator-name = "VDD_5V";
> > +		gpio = <&expander0 8 GPIO_ACTIVE_HIGH>;
> > +		enable-active-high;
> > +	};
> > +};
> > +
> > +&eqos {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_eqos>;
> > +	phy-supply = <&reg_baseboard_vdd3v3>;
> > +	phy-handle = <&ethphy0>;
> > +	phy-mode = "rgmii-id";
> > +	status = "okay";
> > +
> > +	mdio {
> > +		compatible = "snps,dwmac-mdio";
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		ethphy0: ethernet-phy at 0 {
> 
> Unless I'm mistaken, the PHYs are both at address 1. Address 0 works as
> it's the broadcast address, but is there a good reason not to use the
> real address ? Same below.

Didn't verified the phy-addr since it was working after respecting the
power-delays. I will give it a try and assign the correct address.

Regards,
  Marco