• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 33 subscribers
  • Views 617 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: tps65982: hpd status bit, aux muxing and gpio

user6310225
Intellectual 320 points
Part Number: TPS65982

Hi,

Our device with tps65982 is configured as a dp-alt-mode source. When plugging in a dp-alt-mode adapter (that works flawlessly when attached to e.g. a Laptop with usb-c) the tps65982 negotiates DP alt mode successfully (verified by data status register 0x5f) and DP sid status (0x58) however DPStatusRX in 0x58 never changes the HPD state (Bit 7), other pars of DPStatusRX look valid. I have not used a PD analyzer.

- How can i get more debugging information why hpd is never toggled (without a protocol analyzer)?

- Is that bit solely responsible for triggering the tps65982 GPIO4 when acting as DP source ?

- Is alt lane muxing dependent on hpd status or are they already muxed after dp-alt-mode contract negotiation?

(Tried retriggering contract via `AMDs` 4cc command does not change the hpd status).

Thanks for any pointers!

  • 0
    TI__Genius 12700 points

    Hello,

    I would recommend trying to get a PD analyzer to see exactly which messages are being sent and their data, this would help to see if the HPD Attention message was sent or not. However, you could debug some more by measuring the voltage on the HPD pin itself from both devices. A possible issue could be that your GPIO4 may not be configured correctly, or the HPD timing may be off so you could also capture it using a scope. The DP Status Register like you mentioned will help the most here to see all of the configurations together.

    As far as the bit itself, yes there are some timing requirements that must be met based on the VESA DP Specification for proper operation. 

    For the lane/pin assignment configuration, they must be consistent on both the UFP and the DFP side to configure correctly. If they are correct the DP Configure message will be sent and there shouldn't be any errors and yes this would happen before the HPD attention message. 

    If you have not already, I would recommending checking out the DisplayPort Alternate Mode application note, particularly sections 4 and 6 as they will help to see the correct operation for DP and some debugging steps to take.

    Thank you,

    Hari

  • 0 in reply to Hari Patel1
    Intellectual 320 points

    Hi Hari,

    thanks for the prompt response. I had checked the `DisplayPort Alternate Mode application note` where i got hints from.It gives great detail on the message flow but i don't see it talking about when muxing/gpio events happen and since there's no firmware source code i unfortunately can't check myself.

    Could you clarify on the above points please:

    - Is the hpd bit in the attention message sent by the UFP_D responsible for flipping GPIO4 to high on the DFP_D tps65982 (when configured accordingly) ?

    - When do the DP aux lanes on the DFP_D side get muxed to SBU1/2 via the tps65982? When the  UFD_D sends the `Attention` message or earlier (e.g. in Step 11 of the `4 USB PD and VESA DP Alternate Mode Flow` described in the above document.

  • 0 in reply to user6310225
    TI__Genius 12700 points

    Hello,

    Yes that document will greatly help to understand the full process and requirements and such with examples using the TUSB1046. 

    For the HPD bit, yes the UFP_D must send the Attention message to the DFP_D and once the UFP_D can confirm that the HPD timing requirements are met, it will update the IRQ bit to 1, which would be the GPIO.

    For the DP muxing, yes that would happen before the Attention message, as this would be the last step of the process to turn on HPD.

    Thank you,

    Hari

  • 0 in reply to Hari Patel1
    Intellectual 320 points

    Thanks for providing these details. That's what i was looking for. I can see now that my DFP_D hits a protocol error after negotiating alt-mode in IntEvent1 which might be related. I'll open a separate issue for that once i have more details.