TDA4AH-Q1: PCIe LTSSM State Encoding

Part Number: TDA4AH-Q1

Tool/software:

Hello TI,

Could you please provide the actual encoding of the LTSSM_STATE field of the LINKSTATUS register ?

I have a gen3x2 link up and active (TDA4AH is the RC, PCIe instance 0), but the LTSSM_STATE reads 0x10 (Recovery.Idle) where I expected to read 0x11 (L0), as per the PCIe Specification. I also read 4b0001 in LINK_POWER_STATE, indicating L0 state.

The Linux SDK never checks for the LTSSM state, only the LINK_STATUS, hence my question here.

Are LTSSM state values encoding different from the norm ?

Thanks in advance for your time and answer.

Best regards

  • Hi Arthur,

    My understanding is that the PCIe block follows PCI Express Base Specification Revision 4.0 from PCI-SIG, and LTSSM_STATE encoding value 0x10 corresponds to L0, while 0x11 corresponds to Rx_L0s.Entry. The encoding starts at Detect.Quiet at 0x0, and increments for each state defined in the specification with the exception of Recovery.Equalization states as they are encoded in the 0x2X range and the unreachable Polling.Speed state.

    Could you link the specification that says LTSSM_STATE 0x10 corresponds to Recovery.Idle for future reference? So far, I could only find Intel's encoding that adds PreDetect.Quiet and Detect.Wait states that are not defined in the PCI-SIG specification which offsets the encoding value to make L0 correspond to 0x11: https://www.intel.com/content/www/us/en/docs/programmable/683111/21-1/ltssm-monitor-registers.html 

    Regards,

    Takuma

  • Hello Takuma,

    Thanks for your answer, hope you're doing great.

    The PCI-SIG PCI Express 4.0 Base Specification (that you can now find freely online) does not specify any proper encoding of LTSSM states (unless i'm useless at reading it, which is highly possible Upside down ).

    Going through the PCIe driver(s) within the Linux Kernel that you find within the Linux SDK, the only L0 state values that I can find are defined to 0x11 (like in pcie-designware.h), but never defined anywhere in the Cadence-specific driver. Why are none of the pcie drivers within the kernel compliant with the Base Spec then ?

    When taking away PreDetect.Quiet, Detect.Wait, Polling.Speed and the Recovery.Equalization states/sub-states, we get to 0x0F when strictly incrementing so there must be a catch somewhere.

    Thanks in advance again for answering my (possibly) senseless questions but I'm a bit confused now.

    Best regards

  • Hi Arthur,

    You are right in that PCI-SIG's specification does not specify LTSSM state encoding. So I was confused when you mentioned that the specification says 0x11 is L0. I was hoping to learn from you as well to see if there is a specification document that I was not aware of, so if you find something please let me know.

    There is no public documentation from Cadence that I can find that states L0 is 0x10, but I can assure you that L0 is 0x10 for this particular Cadence IP used in TDA4AH. If you are very curious, you may contact Cadence to get a NDA to obtain their registers and LTSSM encoding. For the Cadence IP used for TDA4AH, 0x1X looks to be reserved for L0/L1/L2 states, where L0 is 0x10, Rx_L0s.Entry is 0x11, etc, etc... , so 0x0F is skipped. Then, 0x2X starts from Disabled state and increments until Hot Reset, then goes into the Recovery equalization states. 

    I assume that because the specification I can find on Intel's website adds two extra states (PreDetect.Quiet and Detect.Wait), 0x00~0x10 are all used. And that is the reason why L0 is 0x11 instead of 0x10. If there is specification from PCI-SIG that talks about these extra states, then that could explain encoding differences.

    Regards,

    Takuma

  • Thanks Takuma for confirming the actual encoding.

    I'll mark your answer as resolving for this issue and will keep you updated if I find any relevant document.

    Have a great week-end !