Forum Discussion

JoEl's avatar
JoEl
Icon for Occasional Contributor rankOccasional Contributor
6 years ago
Solved

DisplayPort_TX IP in image video mode

Hi all, I am working on transfer from classic DisplayPort video interface with Hsync, Vsync and DE to video image interface. Reason to switch is suport of adaptive synfchronization which should be ...
  • JoEl's avatar
    JoEl
    6 years ago

    Hi guys,

    Finall answer on whats wrong with picture (protocol)at top is video valid signal. It have to be zero in blanking, and it have to be valid when eol, eof, sof and sol occur.

Deshi_Intel's avatar
Deshi_Intel
Icon for Regular Contributor rankRegular Contributor
6 years ago
Hi Josef, Thanks for the clarification. I checked back DP user guide doc. For DP TX, user is only required to checked "Enable Video Input Image Port" setting in DP source IP to enable adaptive sync feature. I believed you have done so. Byright it should work. 1) May I know what's the exact failure that you see with the adaptive sync feature ? 2) Also to clarify, DP IP adaptive sync feature only support AMD freesync, not Nvidia Gsync. Just to confirm your end monitor is using freesync or Gsync ? 3) Probably stupid question but have you turned on your GPU and monitor adaptive sync feature ? Just to double confirm Thanks. Regards, dlim
JoEl's avatar
JoEl
Icon for Occasional Contributor rankOccasional Contributor
6 years ago

Hi dlim,

1)I might described my problem badly - we want to use clock enable at video_im_interface since there is table refering to feature that data don't need to be valid at every clock cycle and you are able to prolong period by deasserting txN_im_valid and slow down output for balancing input fifo. Sorry for wrong interpretation.

2) our end device is generator/checker for now and we are able to see whats going on in cable.

My current problem is that I generate correct data for tx_im_interface but HW checker doesn't see any valid video. As I have attached I generate valid, sof, eof, sol, eol... only thing is that we deassert video image valid on every second cycle as you can see in picture but according to design guide this should not be a problem.

we find that when internal pattern generator is used, MSA params were calculated correctly which is not with HDMI source (same rate only difference is video valid deaserting) but link isn't trained and loop in training mode....so nor generator nor HDMI generate valid output.