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 = <®_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 = <®_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 = <®_baseboard_vdd3v3>;
> > + phy-handle = <ðphy0>;
> > + phy-mode = "rgmii-id";
> > + status = "okay";
> > +
> > + mdio {
> > + compatible = "snps,dwmac-mdio";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ethphy0: ethernet-phy@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
