Hello TI group,
We are currently designing a card with a couple of DP83867s. We use them in SGMII mode where the SGMII side is connected to an FPGA doing the MAC work. We have the whole datapath running when we connect to an "old router/switch" that doesn't support EEE as specified in IEEE 802.3 section 6. In the "old router" set-up we see Auto-negotiation completes in the MDI and SGMII sides, all registers via MDIO look good in the PHY, link is up, runs error free.
When the link is connected to the "new router" which supports EEE, then we see the following:
1) MDI autonegotiation completes (1Gbps, link up)
2) SGMII side starts autonegotiation, we receive the rx_config_word as specified by IEEE, 0x9801 as the mr_adv_ability (ability advertised), we ACK it and then we get the ACK back. We can see that the SGMII_AUTONEG_TIMER is 2uS (as defined in DP83867 reg 0x0031), after the DP83867s ACK we get 2uS of IDLES (0xBC50) and then 20uS of 0xBC9A which seems to be the EEE_LPI (Low Power Input opcode). This command is telling the FPGA (MAC) to go to sleep according to the EEE spec. The PHY will REFRESH and eventually send a WAKE command to the MAC.
Unfortunately our MAC does not handle LPI commands, so we were wondering if there is a register you could recommend us tweaking on the DP83867 so that the DP83867 does not advertise EEE, or a way to stop the new router and DP83867 to complete MDI auto negotiation with LPI on...?
We need a way to stop this LPI mode, the router and the DP83867 seem to be conspiring against us to get this LPI mode in when we can't handle it... ;)
Thanks in advance, regards.
-Ulises
