Zynqmp: DisplayPort clocking and dts settings

[jawbone_101]

Hello all,

Looking for help/advice/clarification for DisplayPort clocking and corresponding dts setting. I've read several threads regarding the subject in the forums, but I am still unclear on the clocking and dts requirements.

This is a custom board with a XCZU2EG-1SFVC784 production device (not ES). I am using Vivado 2017.1.

I am using the Xilinx 4.9 git repos  (I am not using PetaLinux)

I've monitored this thread for clues:

https://forums.xilinx.com/t5/DSP-and-Video/MPSoC-DisplayPort-no-picture-on-ZCU102/td-p/711388

I am using PS_MGT_TX lanes 0 and 1 and PS_MGT ref clock 2 for DisplayPort. I am not using any other MGT lanes.

I am using a Si5338 clock generator for the PS_MGT ref clock inputs. It drives all four ref clocks. This device is configured once by the fsbl. All four outputs are configured for 1.8V LVDS differential 27.0000 MHz.

I do not have Live Video nor Live Audio enabled in "PS-PL Configuration"

I do get a frame buffer. I am using "fbset" to see if any information about the screen is detected.

When plugged in my eDP LCD (1920x1080)

fbset

mode "1920x1080"
    geometry 1920 1080 1920 2160 16
    timings 0 0 0 0 0 0 0
    accel true
    rgba 5/11,6/5,5/0,0/0
endmode

When plugged into a random computer monitor (1920x1200) (requires a reboot)

fbset

mode "1920x1200"
    geometry 1920 1200 1920 2400 16
    timings 0 0 0 0 0 0 0
    accel true
    rgba 5/11,6/5,5/0,0/0
endmode

So I am inferring that it is partially working. Seems to detect the monitor's resolution, but as mentioned in other threads, there is no timing information. I have attached the dmesg log and the top level dts file. Note in particular the following:

[drm:xilinx_drm_crtc_mode_set] *ERROR* failed to set a pixel clock
[drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:27:crtc-0]

Finally, the questions:

1) Do I need to have Live Video enable and connect a clock to port "dp_video_clk_in"

2) Does the external clock generator driving PS_MGT ref clocks need to be set to something other than 27.000 MHz?

3) I've read that "xilinx_drm", in the dts file, needs a fake clock (per the line above). Is this still true?

4) What do I need to add or remove to the attached dts file as it relates to the DisplayPort functionality.

Thanks a lot I know this was a long post.

All help appreciated.

[florentw]

Hi @jawbone_101,

1) Do I need to have Live Video enable and connect a clock to port "dp_video_clk_in"

-> No, not if you only wnat to use the PS for video. The live input is mainly for Video coming from the PL (see UG1209 Design 2 for a design using only the PS (no live input))

2) Does the external clock generator driving PS_MGT ref clocks need to be set to something other than 27.000 MHz?

-> No need to have a different reference clock but you can (from UG1085):

3) I've read that "xilinx_drm", in the dts file, needs a fake clock (per the line above). Is this still true?

4) What do I need to add or remove to the attached dts file as it relates to the DisplayPort functionality.

Not sure about this but the default device tree should be available with the kernel from Xilinx git. The DP should be included.

Regards,

Florent

[jawbone_101]

Thanks for the reply. Still no display yet, but have a whitelist monitor on order. Maybe that will help.

[jawbone_101]

Whitelist monitor made no difference.

[florentw]

Hi @jawbone_101,

You may want to start with UG1209. It is for ZCU102 but it is quite simple and you can apply it to your board.

Hope that helps,

Regards,

Florent

[jawbone_101]

Thanks for the reply. I have seen this UG, it's quite helpful however I an not using Petalinux. I am using Xilinx's GitHub Linux code.

[florentw]

Hi @jawbone_101,

Could you try first with petalinux? Then in your petalinux project you will have the device tree, the kernel etc... You will just have to replace every element one by one to know what is failing on your build.

Regards,

Florent

[jawbone_101]

I now have a working DisplayPort interface.

As usual, it was a combination of things.

1) Xilinx support informed me about VPLL usage, requirements / limitations. It is now published here: AR for VPLL

2) Needed to go back to using zynqmp-clk-ccf.dtsi instead of zynqmp-clk.dtsi. This was initially done because I could not access IP in the PL. I found this thread:  AXI read hangs

It solved my problem temporally, but the real solution was to add "clk_ignore_unused" in bootargs.

3) I used the latest DTG files from Xilinx and let SDK build the files. I then added the "extra" settings for my custom hardware. 

[jawbone_101]

Additionally, I did NOT have to go to Petalinux to solve this.

[jawbone_101]

Forgot the clock settings.

The PS GMT clock is set to 27 MHz. I am using input 1.

Live Video does NOT have to be set to 1. Which also means there is no need for a 148.5 MHz pixel clock in the PL.

Back to VPLL

I was told numerous times to use the UG1209 Design #2 as the example; however, the settings shown to me (via a help ticket) did not match. Here's what I ended up with in case it helps anyone else.

[ibaie]

As posted in a different post thread, an AR#69764 has been released to address this issue. 

[vcouvert]

Hi all,

We have quite the same problem on a ZU3EG board. Our SI5338, configured via FSBL, seems to works correctly (the PL part use one of the clocks (the 300Mhz one) to light a LED on the board after division) but the display does not work.

But if we reset the board (SOM_RESET_IN pin) and use an other FSBL which does not configure the SI5338 to boot (using an other SD card) then the display works...

Any idea about what is the source of this issue?

Regards.

PS : we used Vivado/Petalinux 2016.4

[ibaie]

Hi @vcouvert,

Did you check the AR#69764 and ensure that your FSBL follows the guidelines?

[vcouvert]

Hi @ibaie,

Thanks for your answer.

It seems that AR#69764  is related to 2017.1/2017.2 but we use version 2016.4, do you confirm?

About FSBL guidelines, can you tell me more?

Regards.

[vcouvert]

Hi @ibaie,

We made some other tests and fixed a bug (DPAUX signals mapped to EMIO pins instead of MIO), now we can see in /var/log/Xorg.0.log that communication between screen and displayport block works but we have an other error message during kernel boot "[drm:xilinx_drm_dp_mode_set] *ERROR* failed to configure link values"

Any idea about what could lead to this issue?

Regards.

[ibaie]

Hi @vcouvert,

With the FSBL mention I was just trying to point that the FSBL used to configure the PSU was generated with the mentioned settings in the AR. At the end of the day the FSBL is the piece of software that reflects your vivado settings.

I'm not sure about the issue by itself, you can take a look to the xilinx drm driver code in github and try to figure out the root cause.

[vcouvert]

Hi @ibaie,

Thanks for your reply. We found the issue (a clock inversion for DisplayPort block).

Regards.

[wen.k]

>>We made some other tests and fixed a bug (DPAUX signals mapped to EMIO pins instead of MIO)

Do you mean "DPAUX signals mapped to EMIO pins" is correct?

Why "mapped to MIO" is a bug?

Look forward to your reply！

wen.k

[vcouvert]

Hello,

Depending on your hardware, it can be OK or not.

For our design (UZ3EG), the right mapping was DPAUX linked to MIO (as on electrical schematics).

Regards.