Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_ISAAC] Section related to 1 second time to enter LPI mode for EEE

Also, related to the topic of EEE, do we need to look into the exchange of TLVs for exchanging EEE parameters?

A potential reason to look into TLVs is to establish periodicity (as opposed to “On Demand” operation). In my opinion, “On Demand” operation has potentially severe latency and “packet jitter” issues in automotive camera applications.

If TLVs are required from an application point of view, it should be noted that this would involve additional delay in PHY’s ability to enter low power mode till this process is completed.



78.4.1 Data Link Layer capabilities timing requirements

An EEE link partner shall send an LLDPDU containing an EEE TLV within 10 s of the Link Layer

capability exchange being enabled when both the variables dll_enabled and dll_ready are asserted.

An LLDPDU containing an EEE TLV with an updated value for the “Echo Transmit Tw_sys_tx” field shall be

sent within 10 s of receipt of an LLDPDU containing an EEE TLV where the value of “Transmit Tw_sys_tx”

field is different from the previously communicated value.

An LLDPDU containing an EEE TLV with an updated value for the “Echo Receive Tw_sys_tx” field shall be

sent within 10 s of receipt of an LLDPDU containing an EEE TLV where the value of “Receive Tw_sys_tx”

field is different from the previously communicated value.

Thanks
Kamal


From: Kamal Dalmia <kamal@xxxxxxxxxxxxxx>
Date: Thursday, July 18, 2024 at 10:00 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx <STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx>
Subject: [802.3_ISAAC] Section related to 1 second time to enter LPI mode for EEE
CAUTION: This email is from an external origin!



All,

Following are the sections that prevent PHYs supporting EEE from entering low power mode (in either direction) for 1 second in the beginning.


78.1.2.1.2 Semantics of the service primitive



The semantics of the service primitive are as follows:

LP_IDLE.request (LPI_REQUEST)

The LPI_REQUEST parameter can take one of two values: ASSERT or DEASSERT. ASSERT initiates the

signaling of LPI to the link partner. DEASSERT stops the signaling of LPI to the link partner. The effect of

receipt of this primitive is undefined in any of the following cases:

a) link_status is not OK (see 28.2.6.1.1)

b) LPI_REQUEST=ASSERT within 1 s of the change of link_status to OK

c) The PHY is indicating LOCAL FAULT

d) The PHY is indicating REMOTE FAULT


46.4.1 LPI messages

LP_IDLE.indication(LPI_INDICATION)
A primitive that indicates to the LPI client that the PHY has detected the assertion or de-assertion
of LPI from the link partner.
Values: DEASSERT: The link partner is operating with normal interframe behavior (default).
ASSERT: The link partner has asserted LPI.

LP_IDLE.request(LPI_REQUEST)
The LPI_REQUEST parameter can take one of two values: ASSERT or DE-ASSERT. ASSERT
initiates the signaling of LPI to the link partner. DE-ASSERT stops the signaling of LPI to the link
partner. The effect of receipt of this primitive is undefined if link_status is not OK (see 28.2.6.1.1)
or within 1 s of the change of link_status to OK.


Thanks
Kamal


________________________________________________________________________
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1

________________________________________________________________________
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1