| Message ID | 20210405112953.26008-1-michael.wei.hong.sit@intel.com |
|---|---|
| Headers | show |
| Series | Enable 2.5Gbps speed for stmmac | expand |
> The limitation is not on the MAC, PCS or the PHY. For Intel mgbe, the > overclocking of 2.5 times clock rate to support 2.5G is only able to be > configured in the BIOS during boot time. Kernel driver has no access to > modify the clock rate for 1Gbps/2.5G mode. The way to determined the > current 1G/2.5G mode is by reading a dedicated adhoc register through mdio bus. > In short, after the system boot up, it is either in 1G mode or 2.5G mode > which not able to be changed on the fly. Right. It would of been a lot easier if this was in the commit message from the beginning. Please ensure the next version does say this. > Since the stmmac MAC can pair with any PCS and PHY, I still prefer that we tie > this platform specific limitation with the of MAC. As stmmac does handle platform > specific config/limitation. So yes, this needs to be somewhere in the intel specific stmmac code, with a nice comment explaining what is going on. What PHY are you using? The Aquantia/Marvell multi-gige phy can do rate adaptation. So you could fix the MAC-PHY link to 2500BaseX, and let the PHY internally handle the different line speeds. Andrew
> > The limitation is not on the MAC, PCS or the PHY. For Intel mgbe, the > > overclocking of 2.5 times clock rate to support 2.5G is only able to > > be configured in the BIOS during boot time. Kernel driver has no > > access to modify the clock rate for 1Gbps/2.5G mode. The way to > > determined the current 1G/2.5G mode is by reading a dedicated adhoc > register through mdio bus. > > In short, after the system boot up, it is either in 1G mode or 2.5G > > mode which not able to be changed on the fly. > > Right. It would of been a lot easier if this was in the commit message > from the beginning. Please ensure the next version does say this. > > > Since the stmmac MAC can pair with any PCS and PHY, I still prefer > > that we tie this platform specific limitation with the of MAC. As > > stmmac does handle platform specific config/limitation. > > So yes, this needs to be somewhere in the intel specific stmmac code, > with a nice comment explaining what is going on. > > What PHY are you using? The Aquantia/Marvell multi-gige phy can do rate > adaptation. So you could fix the MAC-PHY link to 2500BaseX, and let the > PHY internally handle the different line speeds. > Intel mgbe is flexible to pair with any PHY. Only Aquantia/Marvell multi-gige PHY can do rate adaption right? Hence, we still need to take care of others PHYs. Thanks for all the comments, will include them in v3. Weifeng
> Intel mgbe is flexible to pair with any PHY. Only Aquantia/Marvell > multi-gige PHY can do rate adaption right? The Marvell/Marvell multi-gige PHY can also do rate adaptation. Marvell buying Aquantia made naming messy :-( I should probably use part numbers. > Hence, we still need to take care of others PHYs. Yes, it just makes working around the broken design harder if you want to get the most out of the hardware. Andrew
On Wed, Apr 07, 2021 at 02:44:39PM +0200, Andrew Lunn wrote: > > Intel mgbe is flexible to pair with any PHY. Only Aquantia/Marvell > > multi-gige PHY can do rate adaption right? > > The Marvell/Marvell multi-gige PHY can also do rate > adaptation. Marvell buying Aquantia made naming messy :-( > I should probably use part numbers. > > > Hence, we still need to take care of others PHYs. > > Yes, it just makes working around the broken design harder if you want > to get the most out of the hardware. FYI, we really need to come up with a good solution to the rate adaption issue. What we have today really is not good. For example, take a MAC that supports only 2500base-X connected to a PHY that does rate adaption from 2500base-X to media speed. So, the PHY could be capable of 10, 100, 1G and 2.5G media speeds, and would advertise those in its supported mask. The MAC however would only report (via the validate callback) support for 2.5G speed because that's all that 2500base-X supports. What we really want when a rate adapting capable PHY is connected is to ignore what ethtool link modes the MAC supports beyond "does it support this interface type" and just use the PHY supported mask. However, that's another property of the PHY that we need to know from phylib, and it's not clear when that property should be made available. As we know from Marvell PHYs, it depends on the configurable MAC_TYPE setting, so could only be available once we've selected an interface mode for the PHY. On the other hand, we might need to know what interface mode(s) are available from the PHY and MAC to select an appropriate mode. This is not easy problems to overcome; I have had some patches for some time which allow some combination of MAC and PHY to advertise which interface mode(s) they support but I haven't been entirely happy with them to push them upstream - and it would be another phylink API change which means having to maintain the new and old code until everything has been updated (thereby making stuff a lot more complex.) After the last round of phylink API updates and the hostility from people over that, this is a big demotivating factor. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!