• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 33 subscribers
  • Views 1250 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TPS65982: VCONN swap timing in PD negotiation

Takashi Onawa
Genius 13200 points
Part Number: TPS65982

Hi Team,

DP alt mode specification requests sending VCONN swap message prior to DR_swap message(Please find "5.1.2 UFP_D on a USB Type-C Receptacle" in VESA DisplayPort Alt Mode on USB Type-C Standard), but TPS65982 doesn't seem to compliant the manner. 
Since DR_swap is issued before VCONN_swap, My customer is facing interoparability issue when connecting to Macbook.

Let me ask some question to clarify our device behavior on VCONN swap.

1. Are there any register to change the sent timing of Vconn swap massage?

2. How does TPS65982 behave when DR_swap is rejected?

3. How does TPS65982 behave when port partner returns "Wait" message against DR_swap?

Regards,

Takashi Onawa

  • 0
    TI__Genius 16370 points

    Takashi-san,

    I've an older version of the specification (1.0) and I don't see Section-5.1.2 in this document - Can you detail the requirement? I'm not aware of any requirements that force a VCONN-Swap before DR-Swap.

    BTW, which firmware version are you using and what's the IOP issue w/ Macbook? Please as well share the PD logs.

    And to answer your other questions:

    • Ans-1: No
    • Ans-2: The device would no longer request for DR-SWAP (DRS) to the role that was rejected by the far-end. Now, this could have feature impact - One example: Assuming 982 is running a laptop configuration and its DRS request to DFP is rejected by the far-end, the laptop wouldn't communicate w/ the cable and will not enter TBT mode subsequently since PD2 specification mandates a port to be DFP to communicate w/ the cable.
    • Ans-3: The device waits for 'tDRSwapWait' time (defined in PD specification) and resend DRS request

    BR,
    Praneet

  • 0 in reply to Praneet Kumar
    TI__Genius 13200 points

    Hi Praneet-san,

    Thank you answering clearly.
    The document was updated in last November, the latest version is 1.0b(Maybe you are referring version 1.0a). And they use FW version : 3_10.

    Here is the detail of the IOP issue
    - USB line is stack because TPS65982 can not be UFP_U when connecting to Power off state MacbookPro.

    At first, their product is Monitor, so they expect TPS65982 in their application will be Source/UFP_U/UFP_D whenever connected to any partners. But When their product mounted our TPS65982 is connected to Power off state MacbookPro, TPS65982 fall into Source/DFP_U/UFP_D at the end of PD communication. Since their product designed to behave as UFP_U, USB line is stacked in this situation(DP line is available though).

     

    Here is the explanation of scenario which they are facing.
    [USB line stacked case]
    1. Their product become DFP_U/Source when connecting
    2. Since TPS65982 prefers to be UFP_U, it sends DR_Swap to MacbookPro
    3. MacbookPro rejects the DR_Swap message
    4. TPS65982 sends Vconn_Swap to MacbookPro and it's accepted
    5. TPS65982 issues "Discovery Identify" and starts to Alt mode negotiation.
    6. Finally, PD negotiation is finished as TPS65982 is set to DFP_U/UPF_D/Source

     Since TPS65982 is DFP_U and it doesn’t have DFP_U functionality, Communication of the USB line will be stacked.

    According to their surveys, MacBookPro in Power off state seems to "reject" DR_swap message during some hundred ms after connected a partner.
    In other hands, it returns "Wait" for Vconn_Swap message, so if TPS65982 could send Vconn_swap prior to DR_Swap, this issue was avoidable.

     [Questions]

    1. Are there any way to change the order of DR_swap and Vconn_swap(let me ask again just in case)?
    2. Do you have any ideas to set the TPS65982 as UFP_U/UPF_D/Source at the end of PD communication?

    Regards,

    Takashi Onawa

  • 0 in reply to Takashi Onawa
    TI__Genius 13200 points
    Hi Praneet-san,

    Any comments?

    Regards,
    Takashi Onawa
  • 0 in reply to Takashi Onawa
    TI__Genius 16370 points
    Takashi-san, Is this issue same as e2e.ti.com/.../678998 If yes, I'd want to close one and track the other. IMO, closing this and having the customer's thread open would be appropriate.

    -/Praneet
  • 0 in reply to Praneet Kumar
    TI__Genius 16370 points
    Takashi-san, I'm closing this issue as a duplicate of e2e.ti.com/.../678998 - Please use the other thread to post your other queries (if any) on the topic.

    -/Praneet