I am working with a custom board that has a ZynqMP SOC.
The board uses a Marvell QSGMII quad PHY chip (88E1548), a Xilinx QSGMII SERDES transport IP, and the four Ultrascale+ GEM (Gigabit Ethernet MAC)
controllers.
The PHY is a Marvel 88E1548, which is not specifically noted as tested with the macb driver, but another marvell PHY in the family is noted as tested.
Based on some board design issues, 2 of the GEM interfaces can only support 100Mbps transfer rates. The xlinx_phy driver has been augmented to control the speed capabilities advertised on the PHY by writing to the phy_management register on the associated GEM.
This basically works, but is unstable. The BMSR register will at times indicate that auto negotiation has not completed. Restarting the auto negotiation has no effect. Nor does doing a GPIO reset on the Marvell QSGMII quad PHY chip. It takes a reboot or sometimes a power cycle to get the PHY to auto negotiate its link. This is true on both the Gigabit configured PHYs as well as the 100Mbps configured PHYS.
My question is in understanding why the BMCR settings in particular seem to be inconsistent which may be the root of the problem.
To set the PHY speed, the driver does the following:
if (maxspeed == 100 ) {
phy_write(phydev, MII_ADVERTISE,0x181);
phy_write(phydev, MII_CTRL1000,0);
phy_write(phydev, MII_BMCR,0xB300);
netdev_info(phydev->attached_dev,"%s: set max-speed to 100Mbs\n", __func__);
} else {
phy_write(phydev, MII_ADVERTISE,0x1);
phy_write(phydev, MII_CTRL1000,0x0300);
phy_write(phydev, MII_BMCR,0x9340);
netdev_info(phydev->attached_dev,"%s: set max-speed to 1000Mbs\n", __func__);
}
When the BMCR register is read back its value is
0x1540 after 0xB340 is written to it
So it indicates the speed is 1000Mbps after a request to set it to 100Mpbs has been made.
I would expect that after writing the register and immediately reading it back, with no other writes to that register that the speed setting would be as requested.
This inconsistency in the PHY control register setting leads me to a suspicion that the GEM is not properly handling the PHY, leading to failed auto negotiation.
I do not see any possible register settings on the GEM from ug1087-zynq-ultrascal-registers that would allow me to reset the specific GEM to get it back to a recovery state where auto negotiation can succeed without requiring a reboot or power cycle.
Any suggestions for approaching a solution to this are welcome.
