07-06-2018 08:07 AM
I'm having an issue trying out standalone application example for DisplayPort. I'm using xdpdma_video_example files.In our design we are not using any IP cores for DP, we have just included DP in Zynq.
When running on ZCU102 it breaks in function WaitPhyReady (in InitializeTX). Application expects PhyStatus to be 0x13, however, our implementation returns it as 0x15 (so after masking it becomes 0x11 and loop ends with timeout).
Is there any way to detect what could be an issue here? Can it be something other than design approach?
07-09-2018 12:07 AM
I assume you already tried with Linux using the TRD and it is working with the sink you are using?
What configuration did you set for the displayport PLL?
07-09-2018 01:27 AM
I have tried Linux TRD with example dm10. I have used prebuilt images from the Zynq UltraScale+ MPSoC Base TRD 2017.4 and I can see example on monitor using DP cable. I have not yet tried custom design with TRD.
I am not sure what do you consider as DiplayPort PLL configuration. We have been using dp_video_in_clk signal to bring 148.5 MHz as an input for 1920x1080 60 fps display (we have also set corresponding signals for that such as hsync and vsync). We are not using any of the 'out' signals of DisplayPort.
07-10-2018 02:40 AM
I don't think the example are done to be used with the live input clock by default. Did you make any change to the example to select the live input clock?
Is there any reason why you chose the dpdma example and not the dppsu?
07-10-2018 03:20 AM
the reason why I tried dpdma example first is because it is default and I wanted to make sure I can at least see non-live graphics on monitor. I guess I was just following procedure on this site.
Dpdma example shows picture directly from memory so I presumed it was good start. However, I tried using API for live video (in dpdma example), but since it was how I presumed it works I can't be sure if it should be working.
I will have a look at dppsu example to see how it corresponds with the design. If that solves it I'll make sure to mark it as a solution.
07-10-2018 06:26 AM
using xdppsu example I have same PHY_STATUS register value 0x15. It results with timeout in every WaitPhyReady function call. What I wanted to ask is: what is representation of value 0x15 here? (value of bits [1:0] is expected to be '11' but I always have value '01' inside register -> what does value '01' represent here?)
However, using 'workaround' on function WaitPhyReady results with repeated console outputs like this:
+===> HPD connection event detected.
-> Needs training.
!!! Training passed at LR:0x0A LC:1 !!!
After I switch monitor to DP input it keeps repeating this output. Sometimes there are also different messages like these:
<-- Failed to establish/train the link.
!!! Training passed at LR:0x06 LC:1 !!!
After few more custom settings (disabling maxlinkrate and maxlanecount; setting link rate to '1.62 Gbps' and lane count to '1') I can get 'Input Not Support' message on monitor.
What I also noticed here is that in function WaitPhyReady PhyStatus had value of 0x11.
08-01-2018 04:46 AM
The DP_PHY_STATUS register is explained here:
How many lanes are you trying to use? It seems that one lane does not complete reset for some reasons.
08-14-2018 05:58 AM
Do you have updates on this? Was the link enough or not?
08-20-2018 12:32 AM
sorry for the delay. So as I understand from this DP_PHY_STATUS register documentation bits 1:0 represent 2 lanes (1 and 0) each and values represent if reset is done for each of the two lanes where bit 1 represents reset for lane 1 and bit 0 reset for lane 0. I am just making sure because it's not explicitly specified what each value represents (so I had to assume how it works exactly).
So as it stands, we were not able to get picture. We will try to get picture using another board for now. As for this issue I have to assume for now that we're missing out on something here (either in design or using software) so I am not sure if there is anything we can do at the moment (except to wait on DP live stream driver support).
I am not sure what to do about this topic as there was some progress made but the issue withstands. Have you tried reading DP_PHY_STATUS on your setup? If you are able to reset both lanes we could start looking from there when we get back to this isssue (after testing on another Xilinx board).