Messages in this thread | | | Date | Fri, 21 Oct 2022 22:28:09 +0100 | From | "Russell King (Oracle)" <> | Subject | Re: Re: Re: [PATCH v2] net: mtk_sgmii: implement mtk_pcs_ops |
| |
On Fri, Oct 21, 2022 at 09:52:36PM +0200, Frank Wunderlich wrote: > > Gesendet: Freitag, 21. Oktober 2022 um 20:31 Uhr > > Von: "Russell King (Oracle)" <linux@armlinux.org.uk> > > > On Fri, Oct 21, 2022 at 07:47:47PM +0200, Frank Wunderlich wrote: > > > > Gesendet: Freitag, 21. Oktober 2022 um 11:06 Uhr > > > > Von: "Russell King (Oracle)" <linux@armlinux.org.uk> > > > > > Looking at SGMSYS_PCS_CONTROL_1, this is actually the standard BMCR in > > > > the low 16 bits, and BMSR in the upper 16 bits, so: > > > > > > > > At address 4, I'd expect the PHYSID. > > > > At address 8, I'd expect the advertisement register in the low 16 bits > > > > and the link partner advertisement in the upper 16 bits. > > > > > > > > Can you try an experiment, and in mtk_sgmii_init() try accessing the > > > > regmap at address 0, 4, and 8 and print their contents please? > > > > > > is this what you want to see? > > > > [ 1.083359] dev: 0 offset:0 0x840140 > > > [ 1.083376] dev: 0 offset:4 0x4d544950 > > > [ 1.086955] dev: 0 offset:8 0x1 > > > [ 1.090697] dev: 1 offset:0 0x81140 > > > [ 1.093866] dev: 1 offset:4 0x4d544950 > > > [ 1.097342] dev: 1 offset:8 0x1 > > > > Thanks. Decoding these... > > > > dev 0: > > BMCR: fixed, full duplex, 1000Mbps, !autoneg > > BMSR: link up > > Phy ID: 0x4d54 0x4950 > > Advertise: 0x0001 (which would correspond with the MAC side of SGMII) > > Link partner: 0x0000 (no advertisement received, but we're not using > > negotiation.) > > > > dev 1: > > BMCR: autoneg (full duplex, 1000Mbps - both would be ignored) > > BMSR: able to do autoneg, no link > > Phy ID: 0x4d54 0x4950 > > Advertise: 0x0001 (same as above) > > Link partner: 0x0000 (no advertisement received due to no link) > > > > Okay, what would now be interesting is to see how dev 1 behaves when > > it has link with a 1000base-X link partner that is advertising > > properly. If this changes to 0x01e0 or similar (in the high 16-bits > > of offset 8) then we definitely know that this is an IEEE PHY register > > set laid out in memory, and we can program the advertisement and read > > the link partner's abilities. > > added register-read on the the new get_state function too > > on bootup it is now a bit different > > [ 1.086283] dev: 0 offset:0 0x40140 #was previously 0x840140 > [ 1.086301] dev: 0 offset:4 0x4d544950 > [ 1.089795] dev: 0 offset:8 0x1 > [ 1.093584] dev: 1 offset:0 0x81140 > [ 1.096716] dev: 1 offset:4 0x4d544950 > [ 1.100191] dev: 1 offset:8 0x1 > > root@bpi-r3:~# ip link set eth1 up > [ 172.037519] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/1000base-x link mode > root@bpi-r3:~# > [ 172.102949] offset:0 0x40140 #still same value
If this is "dev: 1" the value has changed - the ANENABLE bit has been turned off, which means it's not going to bother receiving or sending the 16-bit control word. Bit 12 needs to stay set for it to perform the exchange.
-- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
| |