Re: [PATCH v2] net: mtk_sgmii: implement mtk_pcs_ops
From: Russell King (Oracle)
Date: Mon Jan 16 2023 - 14:15:31 EST
On Mon, Jan 16, 2023 at 07:50:52PM +0100, Bjørn Mork wrote:
> Made things fail with 2.5G, as expected I guess. But this actually works
> with 1G!
>
> Except for an unexpected packet drop. But at least there are packets
> coming through at 1G now. This is the remote end of the link:
>
> ns-enp3s0# ethtool -s enp3s0 autoneg off speed 1000 duplex full
> ns-enp3s0# ping 192.168.0.1
> PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
> 64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.544 ms
> 64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.283 ms
> 64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.261 ms
> 64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=0.295 ms
> 64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=0.273 ms
> 64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=0.290 ms
> 64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=0.266 ms
> 64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=0.269 ms
> 64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=0.270 ms
> 64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=0.261 ms
> 64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=0.261 ms
> 64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=0.266 ms
> ^C
> --- 192.168.0.1 ping statistics ---
> 13 packets transmitted, 12 received, 7.69231% packet loss, time 12282ms
> rtt min/avg/max/mdev = 0.261/0.294/0.544/0.075 ms
> ns-enp3s0# ethtool enp3s0
> Settings for enp3s0:
> Supported ports: [ TP ]
> Supported link modes: 100baseT/Full
> 1000baseT/Full
> 10000baseT/Full
> 2500baseT/Full
> 5000baseT/Full
> Supported pause frame use: Symmetric Receive-only
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 1000baseT/Full
> Advertised pause frame use: Symmetric
> Advertised auto-negotiation: No
> Advertised FEC modes: Not reported
> Speed: 1000Mb/s
> Duplex: Full
> Auto-negotiation: off
> Port: Twisted Pair
> PHYAD: 0
> Transceiver: internal
> MDI-X: Unknown
> Supports Wake-on: pg
> Wake-on: g
> Current message level: 0x00000005 (5)
> drv link
> Link detected: yes
> .
>
> The MT7986 end looks like this:
>
> root@OpenWrt:/# [ 55.659413] mtk_pcs_get_state: bm=0x81140, adv=0x1a0
> [ 55.664380] mtk_pcs_get_state: bm=0x81140, adv=0x1a0
> [ 58.779924] mtk_pcs_get_state: bm=0x81140, adv=0x1a0
> [ 58.784884] mtk_pcs_get_state: bm=0x81140, adv=0x1a0
> [ 58.789841] mtk_sgmii_select_pcs: id=1
> [ 58.793581] mtk_pcs_config: interface=4
> [ 58.797399] offset:0 0x81140
> [ 58.797401] offset:4 0x4d544950
> [ 58.800273] offset:8 0x1a0
> [ 58.803397] offset:0x20 0x31120118
This looks like it's configured for 1000base-X at this point.
> [ 58.806089] forcing AN
> [ 58.811826] mtk_pcs_config: rgc3=0x0, advertise=0x1 (changed), link_timer=1600000, sgm_mode=0x103, bmcr=0x1200, use_an=1
> [ 58.822759] mtk_pcs_restart_an
> [ 58.825800] mtk_pcs_get_state: bm=0x81140, adv=0xda014001
> [ 58.831184] mtk_pcs_get_state: bm=0x2c1140, adv=0xda014001
> [ 58.836649] mtk_pcs_link_up: interface=4
> [ 58.840559] offset:0 0xac1140
> [ 58.840561] offset:4 0x4d544950
> [ 58.843512] offset:8 0xda014001
> [ 58.846636] offset:0x20 0x3112011b
and here we've reconfigured it for SGMII mode - and we can see the
Mediatek PCS has set the ACK bit (bit 14) in its advertisement
register as one would expect.
> Now, if we only could figure out what the difference is between this and
> what we configure when the mode is changed from 2500base-x to sgmii.
Maybe there is something missing which we need to do on the Mediatek
side to properly switch between 2500base-X and SGMII.
It has a feel of a problem changing the underlying link speed between
3.125 and 1.25Gbps, which is done by the ANA_RGC3 register.
Hmm, maybe the PCS needs to be powered down to change the speed, in
other words, SGMII_PHYA_PWD needs to be set before the write to the
ANA_RGC3 register?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!