On Mon, Jan 28, 2019 at 07:23:49PM +0100, Heiner Kallweit wrote: > On 28.01.2019 16:57, Russell King - ARM Linux admin wrote: > > On Mon, Jan 28, 2019 at 10:46:20AM +0000, Carlo Caione wrote: > >> On 25/01/19 20:27, Heiner Kallweit wrote: > >>> OK, then the description of the referenced patch isn't fully correct > >>> and SmartEEE and EEE are partially compatible, and the problem is > >>> just that we don't know exactly to which extent. > >> > >> Reading from the datasheet at [0] it seems that SmartEEE is compatible with > >> EEE but it's something different. > > > > As I understand it, SmartEEE is just like normal EEE as far as the link > > partner is concerned. The difference is between the PHY and MAC. What > > follows is a simplified understanding of the differences. > > > > In conventional EEE, the MAC takes part in EEE - the local MAC requests > > that its attached PHY enters LPI mode, which signals to the link partner > > PHY that the data stream on the link is going to pause. When the local > > MAC wants to transmit, it first has to signal to the attached PHY that > > the link should be woken up, and the MAC has to wait for the link to > > exit LPI before transmitting. > > > > With SmartEEE, the decision to enter LPI mode is taken not by the local > > MAC but by the PHY instead, since SmartEEE is designed to produce power > > savings for MACs that do not support LPI. Of course, they won't achieve > > the same power saving as real EEE, but they do help to reduce the power > > dissipation in the PHY. > > > > PHYs that support this buffer some data from the MAC, and that buffering > > has to be sufficient for the delay in the link coming out of LPI mode > > without losing data. > > > > As far as the link partner is concerned, EEE and SmartEEE appear the > > same. > > > >> With SmartEEE the PHY can actually enter LPI state even if this is not > >> supported by the link partner since the LPI pattern is generated inside the > >> PHY itself, so auto-implementing a sort of EEE. > > > > It sounds to me like you have this the wrong way round. SmartEEE isn't > > about the link partner not supporting LPI, it's about the local MAC not > > supporting EEE, but still getting some power savings. > > > > EEE (of either kind) can only be entered on the link when both the > > local PHY and remote PHY indicate support for EEE, and have negotiated > > that they support EEE. > > > > Most of the power dissipation is from driving the signals into the > > network cable (which is a lossy environment) to ensure that the far > > end has sufficient signal to keep the link established. SmartEEE is > > about giving a way to enter 802.3az EEE mode on the _cable_ with a > > MAC that does not support EEE. > > > > I've monitored the signals on a link with an Atheros AR8035 with > > SmartEEE mode enabled, and a Marvell 88e1514 PHY in a Marvell switch > > on the other end, and seen the signals on the cable quiesce as a > > result of SmartEEE, but only when _both_ partners are set to allow > > EEE in the negotiated link mode. > > > > If SmartEEE is compatible with EEE on a PHY level, then I'd expect that > advertisement of SmartEEE at different speeds can be controlled via the > standard EEE MMD regs. Is this the case? There is no "advertisement of SmartEEE" - it's just EEE. That is because as far as the link partner is concerned, SmartEEE is just EEE. Carlio posted a link to one of the datasheets for the family. In there, it describes the EEE capability register, which describes what is supported, and the EEE wake error counter register. It also describes the EEE advertisement and link parter advertisement registers. All these registers correspond to the 802.3 section 45 defined MMD and address offsets found in Clause 45 compliant PHYs, and these registers control not only EEE but also SmartEEE. Please stop thinking that SmartEEE is different on the link partner side from EEE - as far as the link partner is concerned, there is no difference. The difference is all to do with the MAC side of the local PHY. -- 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
