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?
