PCI-SIG Technical Support Technical FAQ

The following list of technical FAQs have been generated as a result of answers provided to questions submitted to Technical Support by PCI-SIG members.  Individual names, company names, and any content that might identify a person/company have been removed.  Any additional FAQs identified as appropriate to add to this list, will be added on a quarterly basis.  For the following content, an FAQ is defined as a compilation of two or more questions received during a previous QTR that appear to be basically the same or of very similar content.  Over time, older FAQ entries may be deleted from the list as newer entries are added.

If you have questions relative to the PCI Express Specifications that you will be submitting to Technical Support, please reference your questions relative to the content contained in the appropriate PCI Express Specification.  Please do not reference your questions relative FAQs posted below.  Please submit your Tech Support questions through email via the PCI-SIG web-based submittal process available at www.pcisig.com/developers/technical_support.

PCIe 3.0

1. Section 2.3.1.1 –  If an End Point returns a Completion (Cpl) with no data and Successful Completion status to a memory read request, should this be handled as a Malformed TLP or as an Unexpected Completion?

A compliant device would not return a Completion (Cpl) with no data and Successful Completion status to a memory read request, so normally this should not occur.  If a properly formed Cpl is received that matches the Transaction ID, it is recommended that it be handled as an Unexpected Completion, but it is permitted to be handled as a Malformed TLP.

2. Section 7.5.3 – I have a question relating to BAR registers in Root Port, EP, PCIe-to-PCI Bridge, and a PCIe Switch.  If a PCIe Memory Request is received which has a starting address that hits a BAR, but a length that exceeds the BAR range, how should such a Request to these devices be handled?

A Memory Request that exceeds the BAR range of an End Point,  Bridge, Root Port, or Switch is handled as an Unsupported Request unless one of the following exceptions applies.  An AtomicOp Request that crosses a 4KB boundary is unaligned, and thus must be handled as a Malformed TLP; otherwise, a Memory Request that crosses a 4KB boundary may optionally be handled as a Malformed TLP.

3. Section 4.2.6.2.3 – Can you please clarify the below statement quoted from  section "4.2.6.2.3. Polling.Configuration" of PCI Express 3.0 specification:  Receiver must invert polarity if necessary (see Section 4.2.4.4).  Does this imply the polarity inversion can only be initiated by receiver in Polling.Configuration state or can the inversion happen in Polling.Active state as well?

When polarity needs to be inverted, it must be done before exiting Poilling.Configuration, which permits it to be done in Polling.Active.

4. Section 4.2.6.3.1.2  – The question is regarding Configuration.Linkwidth.Start state in the case of upconfiguration. It is written in the spec:   "The Transmitter sends out TS1 Ordered Sets with Link numbers and Lane numbers set to PAD on all the active Upstream Lanes; the inactive Lanes it is initiating to upconfigure the Link width; and if upconfigure_capable is set to 1b, on each of the inactive Lanes where it detected an exit from Electrical Idle since entering Recovery and has subsequently received two consecutive TS1  Ordered Sets with Link and Lane numbers, each set to PAD, in this substate."  It is not mentioned here if sending of these TS1s should be done ONLY on lanes that detected a receiver in the last time the LTSSM was at Detect state.  Is it so?

The only lanes that can be part of an upconfigure sequence are lanes that were part of the configured link when configuration was performed with LinkUp = zero, and Lanes that failed to detect a Receiver can not be part of that initially configured Link.  Therefore, a Port in the Configuration.Linkwidth.Start state must only transmit TS1s on a subset of the Lanes that detected a Receiver while last in the Detect state, regardless of if it is attempting to upconfigure the Link width, or not.

5. Section 4.2.6.4.2 – According to pg227 of spec, "When using 128b/130b encoding, TS1 or TS2 Ordered Sets are considered consecutive only if Symbols 6-9 match Symbols 6-9 of the previous TS1 or TS2 Ordered Set".  When in Recovery.Equalization and if using 128b/130b encoding, is it required that lane/link numbers (symbol 2) match in TS1s to be considered as consecutive or is it need not match?

The Receiver is not required to check the Link and Lane numbers while in Recovery.Equalization.

6. Section 4.2.6.4.2.2.1 –  In redoing equalization (after a successful completion of one) what settings does an EP use in Recovery.Equalization phase 0?

The Transmitter sends TS1 Ordered Sets using the Transmitter settings specified by the Transmitter Presets received in the EQ TS2 Ordered Sets during the most recent transition to 8.0 GT/s data rate from 2.5 GT/s or 5.0 GT/s data rate.

7. Section 4.2.6.4.3 – When a device has down configured the number of operational lanes, what is the expected power state and characteristics of the unused lanes?

The unused transmitter Lane is put into Electrical Idle.  It is recommended that the receiver terminations be left on. 

8. Section 4.2.6.4.3 – While down configured and a rate change request occurs, do the unused lanes also participate in the rate change?

 The transmitter of the unused lanes remains in Electrical Idle during the speed change.

9. Section 4.2.6.4.1 – The specification says to transition from Recovery.RcvrLock to Recovery.RcvrCfg, upon receiving eight consecutive TS1 or TS2 Ordered Sets. If a Port in Recovery.RcvrLock state receives x (where x < 8) number of consecutive TS1 ordered sets and then receives (8 - x) number of consecutive TS2 ordered sets, should it transition to Recovery.RcvrCfg, OR should it wait for receiving 8 consecutive TS2 ordered sets to transition to Recovery.RcvrCfg (basically discarding the received TS1 Ordered Sets).

 10. Section 4.2.7.3 – PCIe 3.0 Base spec section 4.2.7.4 states that "Receivers shall be tolerant to receive and process SKP Ordered Sets at an average interval between 1180 to 1538 Symbol Times when using 8b/10b encoding and 370 to 375 blocks when using 128b/130b encoding.”  For 128/130 encoding, if the Transmitter sends one SKP OS after 372 blocks and a second after 376 blocks, the average interval comes out to be 374 blocks and that falls in the valid range. So is this allowed, or must every SKP interval count fall inside the 370 to 375 blocks?  
   
At 8 GT/s, a SKP Ordered Set must be scheduled for transmission at an interval between 370 to 375 blocks.  However, the Transmitter must not transmit the scheduled SKP Ordered Set until it completes transmission of any TLP or DLLP it is sending, and sends an EDS packet.  Therefore, the interval between SKP OS transmissions may not always fall within a 370 to 375 block interval.

For example, if a SKP Ordered Set remains scheduled for 6 block times before framing rules allow it to be transmitted, the interval since the transmission of the previous SKP OS may be 6 blocks longer than normal, and the interval until the transmission of the next SKP OS may be 6 Blocks shorter than normal.  But the Transmitter must schedule a new SKP Ordered Set every 370 to 375 blocks, so the long-term average SKP OS transmission rate will match the scheduling rate.

Receivers must size their elastic buffers to tolerate the worst-case transmission interval between any two SKP Ordered Sets (which will depend on the Max Payload Size and the Link width), but can rely on receiving SKP Ordered Sets at a long term average rate of one SKP Ordered Set for every 370 to 375 blocks.  The SKP Ordered Set interval is not checked by the Receiver.  

11. Section 3.5.2.1 –  If you can receive TLPs and flow control DLLPs normally but do not receive any ACK or NAK. Do you exit to DL_Inactive state?

When an Ack or Nak is not received and the REPLAY_TIMER expires, the TLPs in the Transmit Retry Buffer are retransmitted.  The Replay Timer
Timeout error is also reported.

12. Section 7.5.3 –  An Endpoint sends a Memory Request Upstream to a Switch.  How will the Switch determine if it needs to route that packet Upstream or to an Endpoint below another Downstream Port?

Each Port of a Switch contains registers that define Memory Space apertures.  The Memory Base/Limit registers define an aperture for 32-bit non-prefetchable Memory Space.  The Prefetchable Memory Base/Limit & their corresponding Upper registers define an aperture for 64-bit prefetchable Memory Space.  Here is the basic behavior with a properly configured Switch.  If the TLP address falls within the aperture of another Downstream Port, the TLP is routed to that Downstream Port and sent Downstream.  If the TLP address falls within a Memory Space range mapped by any BAR within the Switch, the TLP is routed to the Function containing that BAR. Otherwise, if the TLP address falls within an aperture of the Upstream Port, the TLP is handled as an Unsupported Request.  Otherwise, the TLP is routed to the Upstream Port where it is sent to the Upstream Link or another Function associated with the Upstream Port.

If a Switch implements and supports Access Control Services (ACS), ACS mechanisms provide additional controls governing whether each Memory Request TLP is routed normally to another Downstream Port, blocked as an error, or redirected Upstream even if its address falls within the aperture of another Downstream Port.  See Section 6.12.

13. Section 4.2.3 – Section 4.2.3 states, "After entering L0, irrespective of the current Link speed, neither component must transmit any DLLP if the equalization procedure must be performed, and until the equalization procedure completes."  Does that result in the following sequence:

  1. Negotiate a Link and enter L0.  Do not allow DLLP transmission while in L0.
  2. Change the data rate to 8.0 GT/s and execute the equalization procedure.
  3. Enter L0.  Allow DLLP transmission.

Yes, that is the expected sequence when the autonomous equalization mechanism is executed.  Note that Section 4.2.3 also describes other equalization mechanisms.

14. Section 4.2.6 – Table 4-14 says that Receiver Errors should not be reported in the L0s or L1 states.  During L1 entry, an Upstream Port’s transmitter may be in Electrical Idle while its receivers are not in Electrical Idle.  Similarly, a Port’s transmitters may be in Electrical Idle for L0s, while its receivers are not in Electrical Idle.  In these situations, should the Port report Receiver Errors such as 8b10b errors?

If the receivers are in L0s, Receiver Errors should not be reported.  It does not matter whether the transmitters are in L0 or L0s for reporting of Receiver Errors.  Section 4.2.6.5 specifies the 3 conditions required for the LTSSM to transition from L0 to L1.  Until all of these conditions are satisfied, the LTSSM is in L0 state, and should report Receiver Errors, even if its transmitters are in Electrical Idle.

15. Section 4.2.4.2 – When upconfiguring a Link in the LTSSM Configuration.Linkwidth.Start state, are the Lanes which are being activated required to transmit an EIEOS first when they exit Electrical Idle?

No. Lanes being activated for upconfiguration are not required to align their exit of Electrical Idle with the transmission of any Symbol, Block, or Ordered Set type.  Furthermore, the Lanes are not required to exit Electrical Idle before the LTSSM enters the Configuration.Linkwidth.Start state.

16. Section 2.3.2 – If a Requester receives a CplLk or CplDLk Completion that does not match the Transaction ID for any of the Requester’s outstanding Requests, and the Requester does not support this type of Completion, is the Completion handled as a Unexpected Completion or a Malformed TLP?
 
Only Host CPUs are permitted to generate locked transaction sequences, so Endpoints should never receive CplLk or CplDLk Completions that match their Transaction IDs.  An Endpoint is permitted to handle the case in question either as a Malformed TLP or an Unexpected Completion, depending upon implementation specific factors, such as whether it decodes these types of Completions.  For this case it is recommended that an Endpoint handle it as an Unexpected Completion since it may be the result of a misrouted TLP, and best handled as an Advisory Non-Fatal Error as described in Section 6.2.3.2.4.5.

17.  Section 4.2.6.4.4 – Table 4-5 defines that the valid range of Link Number (Symbol 1 of a TS1 Ordered Set) is 0-31 for Downstream Ports that support 8.0 GT/s or above.  If a Downstream Port in the LTSSM Recovery.RcvrCfg state receives TS1 Ordered Sets with a Link Number that is not in the range 0-31, do they qualify as "TS1 Ordered Sets ... with Link or Lane numbers that do not match what is being transmitted" ?

Yes.  The received Link Number (not in the range 0-31) does not match the transmitted Link Number (in the range 0-31).

18.  Section 4.2.6.4.1 – While in the LTSSM Recovery.RcvrLock state, if a Port receives TS Ordered Sets with a Link or Lane number that does not match those being transmitted on at least one Lane, but receives TS Ordered Sets with Link and Lane numbers that match those being transmitted and the speed_change bit is equal to 1b on at least one other Lane, should the Port transition to the LTSSM Recovery.RcvrCfg state or the LTSSM Detect state after a 24 ms timeout?

The Port should transition to the LTSSM Recovery.RcvrCfg state.

PCIe 2.0

1. Section 4.2.4.1 – What does Link Upconfigure mean? What is it used for?

Link Upconfigure means the device is capable of increasing the link width.  When Upconfigure is supported by both devices on a link, the link width may be reduced to conserve power.  When link use is going to increase, the devices will increase the link width to support the needed high data rate preferred by the device.

2. Section 4.2.4.3 – What is the purpose of the "inferred" electrical idle?

The purpose of the "inferred" electrical idle is to permit a method of detecting an electrical idle that does not use an analog circuit.  Using an analog circuit can be difficult at 5.0 GT/s and the inferred method is an alternate (permitted) method.

3. Section 4.2.6.10.1 – The Loopback slave should wait until Symbol lock is archived after link speed change during Loopback.Entry substate. However, the base spec does not appear to define whether symbol lock should be archieved on some Lanes or all Lanes.

The Loopback slave transitions to Loopback.Active immediately after exiting Electrical Idle following the link speed change.  It attempts to acquire symbol lock on all of the lanes that were active when it entered Loopback.Entry.

4. Section 2.2.4.1 – In the PCIe spec 2.0 page 57, there is a sentence "For Memory Read Requests and Memory Write Requests, the Address Type field is encoded as shown in Table 2-5, with full descriptions contained in the Address Translation Services Specification, Revision 1.0."  If the value of AT field is invalid, what will PCIe do? Will it report an error, and if so, what error will be reported?

Endpoints that do not support Address Translation Services set the AT field to 00b on transmitted TLPs and ignore the AT field on received TLPs.

5. Section 2.2.62. – How does a CPU know a device exists and where the position of the device is?

Configuration softrware reads configuration space address 00h (using different bus, device and function numbers). When it gets a response, it knows a device exists at that ID.

6. Section 4.2.6.4.3 – An Endpoint is in Recovery.RcvrCfg state and has received the 8 required consecutive TS2's. But before it is able to complete sending 16 TS2s, the downstream port sends EIEOS and then starts sending TS1s. At this point, should the Endpoint move to Recovery.Idle after sending 16 TS2s? Or is it required to reset its RX counter and start counting TS1s and try to go to Configuration?

Transition to Recovery.Idle after sending the 16 TS2s since the requirements for that transition are met.

7. Section 5.3.2.3 – Is the following error scenario valid?

- RC sends PME_Turn_off message to EP
- EP doesn't respond with ACK due to delay
- EP responds with PME_TO_Ack message
- EP sends PM_Enter_L23 and not sending ACK.

Can the EP do without ACK?

 The Endpoint is required to send an Ack for the PME_Turn_Off message. There is no valid reason for an extended delay of the Ack.

8. Section 2.7.2.2 – In PCIe 2.0 Spec P.128,a Poisoned I/O or Memory Write Request, or a Message with data (except for vendor-defined 25 Messages), that addresses a control register or control structure in the Completer must be handled as an Unsupported Request (UR) by the Completer. The completer receiving this kind of TLP needs to report error as UR or Poison TLP Received?

The intent is for this error case to be handled as a Poisoned TLP Receieved error. Errata is being developed against the 2.1 Base spec to clarify this. Due to ambiguous language in earlier versions of the spec, a component will be permitted to handle this error as an Unsupported Request, but this will be strongly discouraged.

9. Section 2.9.1 – For a PCIe 2.0 Switch, when upstream port goes to DL_down, it is stated in pg. 131 line 11 that the config registers will be reset, also line 15 says propagate reset to all other ports (which I interpret as all downstream ports, am I right?)

Yes, when a link reports DL_Down the upsteam port on the switch (and all other downstream devices) are reset.

But on line 11 of pg. 130, it says downstream port registers are not affected except status update, do these contradict?

The section 2.9.1 text covers two contexts. The context of a Downstream Port in DL_Down and the context of an Upstream Port in DL_Down. Care must be taken to apply the requirements in this section to the correct context.

10. Section 4.2.6.10.1 – I have a question about LTSSM in Loopback state. When the LTSSM is in Loopeback.Entry(p.233L24), Loopback master will send TS1 with Compliance Receive bit (Symbol 5 bit 4)=0b and Loopback bit=1b and wait to receive identical TS1 with Loopback bit asserted less than 100 ms. In this time, both sides of link are probably in 5GT/s. Then if Loopback slave cannot do Symbol lock, how long does Loopback slave need to wait, and what is the next substate?

The slave stays in Loopback.Active indefinitely until it receives an EIOS (or detects or infers an Electrical Idle). There is not timeout.

11. Section 4.2.6.1.1 – According to Section 4.2.6.1.1 in PCIe Base Specification 2.0, "The next state is Detect.Active after a 12 ms timeout or if Electrical Idle is broken on any Lane".  Does this mean next state is Detect.Active only when electrical idle is broken?

It means the next state is Detect.Active after a 12 ms timeout, or the next state is Detect.Active (prior to the end of the 12 ms timer) if Electrical Idle is broken on any Lane.

12. Section 6.18 – If a Switch supports the LTR feature, which of its ports must support LTR?

If a Switch supports the LTR feature, it must support the feature on its Upstream Port and all Downstream Ports.

13. SECTION 4.2.6.3.5.2 – Based on the PCIe 2.0 spec, Line 13 page 212:  - The next state is Configuration.Idle immediately after all Lanes that are transmitting TS2 Ordered Sets receive eight consecutive TS2 Ordered Sets with matching Lane and Link numbers (non-PAD) and identical data rate identifiers (including identical Link Upconfigure Capability (Symbol 4 bit 6)), and 16 consecutive TS2 Ordered Sets are sent after receiving one TS2 Ordered Sets.  Does the received eight consecutive TS2 Ordered Sets with identical data rate identifiers (including identical Link Upconfigure Capability (Symbol 4 bit 6)) need to match the transmitted TS2 Ordered Sets if the next state is Configuration.Idle?

The received Link number must match the transmitted Link number. The received Lane number must match the transmitted Lane number. The received data rate identifier must be the same on all received lanes (but is not required to be the same as the transmitted data rate identifier). The received Link Upconfigure Capability bit must be the same on all received lanes (but is not required to be the same as the transmitted Link Upconfigure Capability bit).

14. SECTION 7.5.3.6 – Can you please clarify the behavior of a Switch Downstream Port when the Secondary Bus Reset bit is Set in its Bridge Control register?  It is our understanding that a Secondary Bus Reset will not affect anything in the Downstream Port where it is Set, only in components Downstream (i.e. components on or below the secondary bus of that virtual Bridge).   Should the primary side of the virtual Bridge reset or preserve its Requester ID after the Secondary Bus Reset bit is Set?

When software sets the Secondary Bus Reset bit in a Switch Downstream Port, the Downstream Port must not reset any of its own configuration settings, and it must transition the Link below it to the Hot Reset state, assuming the Link is not down.  The description of the Secondary Bus Reset bit in Section 7.5.3.6 states “Port configuration registers must not be changed, except as required to update Port status.” 

15. SECTION 4.2.8 – In the PCIe Base Spec 2.0, Section 4.2.8, page 239, under Key below the table it states -

D           Delay Symbol K28.5 (with appropriate disparity)

What exactly does the term 'appropriate disparity' mean in the above lines from Spec?

Appropriate disparity means that the D symbol must have the correct disparity for the specified sequence of symbols.

16. SECTION 6.1.4 – This question relates to MSI. More specifically this question also relates to the Conventional PCI 3.0 spec (on page 237) for MSI where it states that - The Multiple Message Enable field (bits 6-4 of the Message Control register) defines the number of low order message data bits the function is permitted to modify to generate its system software allocated vectors. Does this mean that the binary value of the LSBs of the message data specifies the vector number? 

Yes (up to a total of 5 bits). Also to avoid confusion for the function, software sets each of the low order message data bits to 0, that correspond to the low order message data bits the function is permitted to modify to generate its system software allocated vectors.

17. SECTION 4.2.6.4.4 – Referring to section 4.2.6.4.4 (Recovery.Idle), our EP is implemented such that it will send Idle data once entry into recovery.idle. If Hot Reset bit is asserted in two consecutive received TS1 ordered set, then we will move to HotReset state. Will the RC respond to the idle data that the EP sends out and falsely trigger into L0 state even though RC is directed to enter into HotReset?

For this case, the LTSSM of the Downstream Port above the Endpoint is already in the Hot Reset state, since that is how it transmitted TS1 Ordered Sets with the Hot Reset bit asserted.

18. SECTION 4.2.6.5 – In Base Spec 2.1 on page 246 line 10, it states that - "If directed" is defined as both ends of the Link having agreed to enter L1 etc. and then refers to Section 4.3.2.1, but there is no such section in the spec. Is there a section in the spec that provides more detail on this? 

The reference in the spec should be to Section 5.3.2.1, which provides more detail (note that this reference will be fixed through upcoming errata to the 2.1 spec). 

19. SECTION 7.5.1.1 – We implement Memory Space Enable and IO Space Enable bit in our Endpoint. If the Endpoint receives a Memory Write TLP when Memory Space Enable bit is not set. How should the Endpoint handle this TLP? Also, if the Endpoint receives a Memory Write TLP and its data payload exceeds Max_Payload_Size when Memory Space Enable bit is not set. How should the Endpoint handle this TLP in each case?

For the first case, the Endpoint must handle the Request as an Unsupported Request. For the second case, it is recommended that the Endpoint handle the Request as a Malformed TLP, but the Endpoint is permitted to handle the Request as an Unsupported Request.

20. SECTION 2.3.1 – What is the correct behavior if a read or write exceeds a bar limit? For example, let's say a BAR is 128 bytes, and the Read or write request to the address space mapped by the BAR is for a size that is larger than 128 bytes. In this case what is the correct response from the device?

It should be handled as an unsupported request.

21. SECTION 4.2.6.4.4 – Is the following lane setting valid: executing a downconfiguration from x4 to x2, with lane0=ACTIVE, lane1=INACTIVE, lane2=ACTIVE, lane3=INACTIVE?

The active lanes must be consecutively numbered lanes starting with lane 0. Your example would configure as a x1 link.

22. SECTION 7.7 –  Is a PCI Express Root Complex required to support MSI?

All PCI Express device Functions (including root ports) that are capable of generating interrupts must implement MSI or MSI-X or both.

23. SECTION 4.2.6.2.1 -- This is in reference to the Polling.Active state as described in section 4.2.6.2.1 -  "Next state is Polling.Configuration after at least 1024 TS1 Ordered Sets were transmitted, and all Lanes that detected a Receiver during Detect receive eight consecutive TS1 or TS2 Ordered Sets or their complement with both of the following conditions."  We have a question relative to the statement “eight consecutive TS1 or TS2 Ordered Sets”.  Our understanding is that it means 8 consecutive TS1 or 8 consecutive TS2. It doesn't mean a mixture of TS1 and TS2.

The transition to Polling.Configuration follows either 8 consecutive TS1s, or 8 consecutive TS2s on all lanes that detected a receiver in Detect.  Note that the intent of the spec also is to allow the 8 to be any mixture of 8 consecutive TS1s or TS2s for this particular case (not necessarily for other LTSSM transitions, however).  Note also that the PCIe 2.0 Errata item A42 (Polling.Active Substate) modifies this section (see Errata item A42 at www.pcisig.com/specifications/pciexpress/base2/).

24. SECTION 6.2.3.2.3 -- If a device encounters more than one error, will it log all the errors or the most significant error only (according to the precedence list).

It is recommended that only the highest precedence error associated with a single TLP be reported.  However, it is recognized that reasonable implementations may not be able to support the recommended precedence order, which is why this is recommended rather than required behavior.

25. SECTION 7.8.6 -- Relative to Bits 3:0 in Section 7.8.6 - Link Capabilities Register, Supported Link Speeds.   Is it OK for my device to support “0010b” and only support 5GT/s (and not support 2.5GT/s)?

A device that supports 5GT/s must also be able to support and
operate at 2.5GT/s.

26. SECTION 4.2.6.2.1 -- Device A has transmitters on 8 lanes.  Device B has transmitters on 4 lanes.  Both devices are connected via a link.  During Receiver Detection sequence in Detect.Active:  Device A detects that Device B has drivers on 4 lanes, and Device B detects that Device A has drivers on 8 lanes.

PCIe Link is symmetric – so each component has the same number of Transmitters as Receivers. Since device B has transmitters on only 4 lanes, it also has receivers on 4 Lanes. Hence it would not be capable of detecting receivers on 8 lanes of device A.

27. SECTION 4.2.6.2.1 -- During Polling.Active, should Device A transmit TS1s on 4 lanes while Device B transmits TS1s on 8 lanes?  Or, TS1s must be transmitted in both directions on the identical number of lanes?

Since device B has transmitters on only 4 lanes, it cannot transmit TS1s on more than 4 lanes.  Device A will transmit TS1s on only the lanes where it detected receivers (and that is a maximum of 4 lanes).

28. SECTION 4.2.6.6.2.2 -- I have an LTSSM L0s question.  Let's say we have an EP that has both its RX and TX in L0s – specifically Rx_L0s.Idle and Tx_L0s.Idle.  Also assume the EP receives and EI exit, and then the receiver transitions from RX_L0s.Idle to Rx_L0s.FTS. - What should Tx_L0s.Idle transition to, or should it stay in the same state?

The transmitter stays in TX_L0s.Idle.