On Fri, 21 May 2021 17:41:37 +0800 Icenowy Zheng icenowy@aosc.io wrote:
Hi Icenowy,
于 2021年5月20日 GMT+08:00 上午5:44:30, Andre Przywara andre.przywara@arm.com 写到:
On Wed, 19 May 2021 21:42:07 +0200 Andreas Rehn rehn.andreas86@gmail.com wrote:
Hi,
h3 and v3s have internal phys and can share the same driver. Furthermore sun8i-v3s-emac is not available, use sun8i-h3-emac
instead
- add emac pins
- enable emac for licheepi-zero-dock as it provides a ethernet port
So first, this is not how we handle DT changes in U-Boot. They would need to go through the Linux tree first, then can be synced back to U-Boot. Sorry.
Looking more into the details:
Signed-off-by: Andreas Rehn rehn.andreas86@gmail.com
arch/arm/dts/sun8i-v3s-licheepi-zero-dock.dts | 11 +++++++++++ arch/arm/dts/sun8i-v3s.dtsi | 10 +++++++++- 2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/sun8i-v3s-licheepi-zero-dock.dts
b/arch/arm/dts/sun8i-v3s-licheepi-zero-dock.dts
index db5cd0b857..083ac11b94 100644 --- a/arch/arm/dts/sun8i-v3s-licheepi-zero-dock.dts +++ b/arch/arm/dts/sun8i-v3s-licheepi-zero-dock.dts @@ -49,6 +49,10 @@ compatible = "licheepi,licheepi-zero-dock",
"licheepi,licheepi-zero",
"allwinner,sun8i-v3s";
- aliases {
ethernet0 = &emac;- };
- leds { /* The LEDs use PG0~2 pins, which conflict with MMC1 */ status = "disabled";
@@ -94,3 +98,10 @@ voltage = <800000>; }; };
+&emac {
- allwinner,leds-active-low;
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&emac_rgmii_pins>;
I don't think this is correct. If I understand correctly, the V3s does not expose any MAC pins, instead relies entirely on the internal PHY. Those pins are not muxed, so don't need any pinctrl properties.
+}; diff --git a/arch/arm/dts/sun8i-v3s.dtsi
b/arch/arm/dts/sun8i-v3s.dtsi
index 0c73416769..35cc4d63f7 100644 --- a/arch/arm/dts/sun8i-v3s.dtsi +++ b/arch/arm/dts/sun8i-v3s.dtsi @@ -342,6 +342,14 @@ function = "csi"; };
emac_rgmii_pins: emac-rgmii-pins {pins = "PD0", "PD1", "PD2", "PD3", "PD4","PD5", "PD7", "PD8", "PD9", "PD10","PD12", "PD13", "PD15", "PD16", "PD17";function = "emac";drive-strength = <40>;};This is wrong (and not needed): The V3s does not expose MAC pins. If I understand correctly, the V3 and V3s share the same die, so the pin controller has those registers, but the whole port is connected nowhere.
i2c0_pins: i2c0-pins { pins = "PB6", "PB7"; function = "i2c0";@@ -468,7 +476,7 @@ };
emac: ethernet@1c30000 {
compatible = "allwinner,sun8i-v3s-emac";
compatible = "allwinner,sun8i-h3-emac";You can't just change the compatible string this way, the original one is there for a reason. In this case the difference is that the V3s does not support Gigabit Ethernet - because the only MAC pins connected are the internal MII ones. I believe the MAC itself could probably still handle GBit, but it can't talk to the outside in this mode.
You got it right. However, we choose to just use v3s compatible on V3/S3 too.
Thanks for the confirmation!
Instead just add the v3s compatible string to the sun8i-emac driver. Assign a new type and add this new type wherever you see H3_EMAC, but not in the RGMII part.
Maybe we can just make v3s situation a copy of h3 one.
Yes, that would work in practice, since we realistically would just never request RGMII through V3s DTs. But it's also easy to solve this properly: case PHY_INTERFACE_MODE_RGMII: .... if (priv->variant != V3S_EMAC) reg |= SC_EPIT | SC_ETCS_INT_GMII;
Cheers, Andre.
Cheers, Andre
syscon = <&syscon>; reg = <0x01c30000 0x10000>; interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;