On Mon, Jan 28, 2019 at 03:26:21PM +0100, Maxime Chevallier wrote: > Hello Russell, > > On Mon, 21 Jan 2019 13:00:30 +0000 > Russell King - ARM Linux admin <li...@armlinux.org.uk> wrote: > > >On Mon, Jan 21, 2019 at 01:29:45PM +0100, Maxime Chevallier wrote: > >> Hello Russell, > >> > >> On Mon, 21 Jan 2019 10:52:06 +0000 > >> Russell King - ARM Linux admin <li...@armlinux.org.uk> wrote: > >> >It's entirely possible that the 3310 switches to different hardware > >> >blocks for 2.5G and 5G speeds, and reading _just_ the 1.4 register > >> >is not sufficient. > >> > >> I agree with you but in that particular case, I think we are reading > >> from the correct device. The datasheet itself says that we should be > >> reading 1.4 and 1.11 as we expect, with 2.5G/5G support being set (these > >> registers are read-only, and the datasheet's values aren't what we > >> actually read). > > > >No, you missed what I was saying. > > > >The 88x3310 is a hybrid device. It contains multiple instances of > >each individual device at different offsets in each MMD address space. > > Ah I see, I indeed thought you refered to the MMDs. > > [...] > > >The exception seems to be the PMA/PMD MMD which I've only discovered > >a single instance. > > Yes there only seems to be one. There are some other registers in the > 1.0xCxxx range, but those who are documented don't help a lot with > determing wether or not these modes are supported. > > I wonder if these values are correctly reported in newer PHY firmware > revisions. > > I've checked other PCS instances, but it seems the one at 3.0x0xxx is > the one used in 2.5/5GBASET.
In the following, I use "subdevice N" to mean instance "N + 1". So the instance at address 0 is the main device and the following instance is subdevice 1. Looking at the PCS, none of them have the 2.5G/5G bits set in the 3310 which is rather interesting, except the one at 3.0 has the EEE bits set in 3.21. You are quite correct that the first instance is used for 2.5G copper, but PCS subdevice 2 also changes as a result of switching down to 2.5G (its transmit fault status clears.) It looks like PhyXS subdevice 3 is used (which is a SGMII/1000base-X MAC facing PHY), is switched to fixed speed mode. It doesn't have what looks like a sensible advertisement either, so my guess is that this will need the MAC side to be configured _not_ to expect the in-band control word in this mode. In other words, it may be SGMII or 1000base-X upclocked to 2.5G speeds - which it is doesn't matter because the difference is in the control word which looks like it's omitted, or if it isn't, doesn't contain useful information. Note that mvpp2 is slightly buggy in this area, and I have a patch set that fixes it up - patches can be found in my "mvpp2" branch, which I'm waiting for my problem reporter to report back after his testing. If you use this patch set, as long as you don't use in-band mode, it should be fine. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
