TPS65987DDK: HPD assertion issue

Hello,

Can you compare the configuration settings?

https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1449145/tps65987d-tusb1146-dp-alt-mode-not-driving-hpd-high/5565021#5565021

Can you confirm the firmware version that you are using?

https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1449145/tps65987d-tusb1146-dp-alt-mode-not-driving-hpd-high/5572488#5572488

Regards,
Chris

Hello,

First of all, for firmware version.
We are using following Firmware version. I believe this is for TPS65987DDK.

And here is result of 0x5f after connecting display.

* 0x108511

It seems that HPD shows "High" (bit 15 show "1".).
I will check another part as well.

BR,

Hi,

I have one question.
According to URL which you show you set following "UFPD Receptacle or DFPD plug pin assignment".
In my configuration, I only set "DPFD Receptacle or UPFD plug pin assignment". It is available when we use DFP_D only ?



BR,

Hi,

I have one additional request.

* Do you have project which you can confirm Alternate mode with TPS65987DDKEVM and Expansion Board ?

I would like to compare your setting with our setting.

Best Regards,

Hello,

For DFP_D only, you are correct to only set the "DPFD Receptacle or UPFD plug pin assignment".  

https://www.ti.com/lit/an/slva844b/slva844b.pdf#page=10

Regards,

Chris

Hello Chris-san,
>I believe the issue is with the setting in the Intel VID Config Register:
Thanks to your advice, we could confirm that HPD is asserted on customer board.

However, we are facing other issue.

* We observed that we can NOT confirm display when we use Type C to Type C cable with customer board.

Here is detail.
We did test with several pattern. We could not confirm display case of type-c to type-c cable with customer board image source.
To check whether this issue is related to cable quality, we did test by using PC as image source. However, when we used PC as image source, we could confirm display on any case of display.
We confirmed HPD is asserted and also confirmed DP signal at near of type-C connector (checked signal after passing through AC coupling (approx +/-600mV) in all following cases.



Finally, we tried to apply setting which you attached to customer board as possible as we can. However, the phenomenon was NOT improved.

Have you ever observed similar condition ?
And if you have any which point we should check ?

Best Regards,

Hello,

I do not have the ability to actually pass data, i would only be able to confirm the signals from the PD (HPD, DP event, cable flip).  How does the display port device know the status of the port?

Regards,

Chris

Chris-san,

>How does the display port device know the status of the port?
We input HPD signal from TPS65987DDK to crosspoint switch(TUSB546) and DP controller.
If HPD is asserted, path from DP controller to type-C output become active.

Best Regards,

Hi Chris-san,

I noticed one difference about CC communication between displayed case of Non-displayed case.
Here is information of PD analyzer about "DISCOVER MODES" from Sink and "DP CONFIGURE" from Source.




According to above, "UFP_U with DFP_D pin assignment" setting was aligned between SNK and SRC to all case which we could confirm display.
However only case which we could NOT confirm display was NOT aligned SNK and SRC.
In this highlighted red case, SNK send its information as "C, E", however SRC is set as only "C".
Meaning of "C" and "E" is different ("C" is for C to C cable and "E" is for C to DP cable). I suspect this difference cause root issue.
Then I have following question.

Q. If  "DISCOVER MODES" parameter of  "UFP_U with DFP_D pin assignment" show multi-assignment like "C", "E", which SRC setting is expected ?

Best Regards,

Hello,

Ryuuichi machida said:

Q. If  "DISCOVER MODES" parameter of  "UFP_U with DFP_D pin assignment" show multi-assignment like "C", "E", which SRC setting is expected ?

C should be selected when C to C cable and E when C to DP cable.

https://www.ti.com/lit/an/slva844b/slva844b.pdf#page=5

Ryuuichi machida said:

Meaning of "C" and "E" is different ("C" is for C to C cable and "E" is for C to DP cable). I suspect this difference cause root issue.

Does this statement align?

https://www.ti.com/lit/an/slla403a/slla403a.pdf

Regards,
Chris

Hello Chris-san,

>Does this statement align?
I understood that you are asking pin assignment for SNK side.
However, SNK side is display, so in my understanding, there is no way to check which line is used in fact..

Is there anyway to know which highspeed line is selected on SRC side ?

Best Regards.

Hi,

Additionaly, I would like to confirm about below as well.

* In our setting, we enabled "support DP v1.3 signaling".
However we use DP v1.1a. In that case, is it OK to enable this setting ?

Best Regards,

Hello,

Ryuuichi machida said:

I understood that you are asking pin assignment for SNK side.

No.  I am trying to understand how the source side muxes the DP information.  If the SNK side is working with the PC then i do not see there being an issue with the sink side.

https://www.ti.com/content/dam/videos/external-videos/en-us/10/3816841626001/what-is-DisplayPort-alt-mode.mp4/subassets/what-is-DisplayPort-alt-mode-presentation.pdf#page=8

Ryuuichi machida said:

Is there anyway to know which highspeed line is selected on SRC side ?

Can you put a scope on the AUX lanes to see what is happening?

Regards,
Chris

Hello,

I do not know.  Would it be possible to share the complete PD log for the excerpts provided here?

Regards,
Chris

Hello Chris-san,

For below, I sent private message to you, and it includes PD analyzer log.
>Would it be possible to share the complete PD log for the excerpts provided here?

Best Regards,

Hi Chris-san,

I sent private message for below about routing information on custom board.
Please check it as well.

>No.  I am trying to understand how the source side muxes the DP information.  If the SNK side is working with the >PC then i do not see there being an issue with the sink side.

Best Regards,

Hello,

Thank you for the additional information.  I will go through the logs and try to have a response by Monday.  It is still very strange to me that this is not working.  Have you confirmed that the GPIO values are correct - CTL0 is always low and CTL1 is always high?  

Regards,

Chris

Hi,

>Have you confirmed that the GPIO values are correct - CTL0 is always low and CTL1 is always high? 
Yes, I confirmed GPIO value is expected by using GUI.

> I will go through the logs and try to have a response by Monday.
Thank you for your confirmation, I will wait for your reply.

Best Regards,
 

Hi, Chris-san,

I have one additional update.

* Additionally, customer tried to use Type C to DP cable. Then they could confirm display in this case.
So we have "no display" problem only case of Type C to Type C cable...

Do you have any feedback for PD log ?

Best Regards,

Hello,

I have gone through the logs and there appears to be no difference in the data source.  In all four cases, the DP_CONFIGURE request is 'C' or 'E' dependent upon if it is the C cable or C to DP respectively, but the configuration request is the same: SET_UFP_U_AS_UFP_D.  

Can you capture the CTL0, CTL1, and FLIP signals and confirm that it is always CTL1 = H, CTL0 = L?

Regards,
Chris

Hello Chris-san,

>Can you capture the CTL0, CTL1, and FLIP signals and confirm that it is always CTL1 = H, CTL0 = L?
We are checking about above from viewpoint of dynamic behavior. Please wait our feedback.

In addition, I have question about protocol analyzer result.
I sent private message and give your feedback about this.

Best Regards,

Hello,

I have reviewed the protocol analyzer response, and I believe i have been able to replicate on my side.  I do have some concerns that the cable is not reporting/responding to the SOP' message but since it works with the PC and not the IO board there may still be an issue that is unclear.  Please retest with another cable that does respond to SOP' message (supports higher data rates) and see if that changes the system performance.

Regards,
Chris

A couple of additional observations and references to similar topics.

With the cable that does not support SOPP (typeC to typeC), it appears that the aux communication is failing. 

With the SOPP (type-c to type-c), the 

References:

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1015177/tps65987evm-using-the-devkit-with-the-10g-expansion-evm-to-do-display-port-alt-mode

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/769995/tps65987-90evm-maximum-resolutions-for-dp-alt-mode

Regards,

Chris

Hello Chris-san,

How can we recognize whether SOPP supported cable or not ?
Our yesterday's debug, we used both emarker cable and non-emarker cable.
In both case, we did not confirm display on monitor.
(Actually, we could confirm abnormal CC swap behavior was solved by using emaker cable.)

Best Regards,   

Hello Chris-san,

Related to following question.
>How can we recognize whether SOPP supported cable or not ?

Q2. Could you please tell me the cable parts number which you confirmed SOPP supported and No SOPP supported ?
(I would like to confirm if we can buy.)
Q3. Is following phenomenon observed on TPS65987DDH EVM as well ?
>If i look at the PD log i can confirm that the SOPP is not available and there is no display on the monitor

Best Regards,

Hi Machida-san,

Chris Sterzik is OoO and will be returning towards the middle of the week next week.

We will see if we can assign an engineer to help in the meantime, but please expect delays.

Ryuuichi machida said:

How can we recognize whether SOPP supported cable or not ?

If you know you have a DFP that will check for SOPP, you can use one of those with a PD analyzer. Some cables may be labeled with that information as well. Otherwise, it may be difficult to tell.

Ryuuichi machida said:

Q2. Could you please tell me the cable parts number which you confirmed SOPP supported and No SOPP supported ?

We may need to wait for Chris S. on this one, I am not too experienced with specific cables. I will check with the team.

Ryuuichi machida said:

Q3. Is following phenomenon observed on TPS65987DDH EVM as well ?

Which phenomenon specifically? Apologies, I will need some assistance getting caught up with this thread.

Thanks and Regards,

Chris

Hello Christopher-san,

>We may need to wait for Chris S. on this one, I am not too experienced with specific cables. I will check with the team.
Thank you for your following up.
We will get customer's board today. So, I would like to confirm difference of phenomenon by using above information ASAP.

>Which phenomenon specifically? Apologies, I will need some assistance getting caught up with this thread.
Chris Sterzik  said that they confirmed following phenomenon.

* If i look at the PD log i can confirm that the SOPP is not available and there is no display on the monitor
* I have also collected logs. with no SOPP the display port is not responding:

According to their reply, It seems that they could not confirm display when they use some of no SOPP supported cable with TPS65987DDK EVM.
What I would like to confirm is you can see same condition under TPS65987DDH EVM.

Best Regards,

Hi Machida-san,

Christopher Lim1 said:

Which phenomenon specifically? Apologies, I will need some assistance getting caught up with this thread.

What I meant by this is what exactly is being tested? Is is just if the TPS65987DDK will check SOP_P? Any active cable should work, you should not need a specific cable number for SOP_P. Do you have a PD log that you can share?

Or is it if DP works with no SOP_P response?

As mentioned before, I'm still trying to understand what the problem is and picking up where Chris S left off.

Thanks and Regards,

Chris

Hello Christopher-san,

>What I meant by this is what exactly is being tested?
----
- 1 -
Here is what Chris-san did.
Chris-san tried to use several type C cable. The test condition is TPS65987DDK is set as DFP and connect display.
Here is detail.

* They used TPS65987DDK EVM with Expansion board (Connect video source to expansion board)
* Sink side is display and use several type C cable.
* According to their reply, it seems they could not confirm display by using some of type C cable.
The common feature is that it looks SOPP is NOT supported or not.

- 2 -
Here is my problem.

* I could not confirm display by using type-C to type-C cable. (We could confirm display by using type-C to HDMI or type-C to DP cable.)
----


>Do you have a PD log that you can share?
Attached(log.zip) is Chris-san sent to me on private message.

Best Regards, 



4403.log.zip

Hello,

Please confirm that the expansion board does not support video (displayPort) when using a type-C to type-C cable that does not support SOPP.   Video does work when using the same cable (and monitor) with a PC.  

The communication to the device controlling the sbu mux is the same for all use cases.  HPD is high, CTL1 is high, and CTL0 is low.  Please note from the thread above that the PD is correctly reporting that the monitor is present and the C and E configurations are the same with regard to the communication between the PD and the mux.  This discussion is getting outside of the PD area and sounds to be more associated with the AUX channel.  Do you have a contact to confirm that the AUX channel supports this use case?  

Regards,

Chris

Hello,

Just curious.  Have you tried to disable AUX snoop enable?

https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1134330/tusb546-dci-no-screen-with-aux_snoop-enabled-and-dockingstation-source-device/4212579#4212579

Regards,
Chris

Hello Chris-san,

>Have you tried to disable AUX snoop enable?
In our custom board, cross point switch TUSB546 is configured as "GPIO mode".
So, we could not change register via I2C. Therefore we tried to change "CAD_SNK/ RSVD1" pin to "H" (Our default setting was "L".)
However, phenomenon was not changed.. (No display with type-C to type-C cable.)

Best Regards,

This is a bit out of scope for the PD team. I will move this to HSD-USB team.

Hi Ghouse,

We are already supporting this issue. Thanks for the help on the PD side.