How to enable DP port in xavier AGX L4T32.4.3

Ok, let me try

nvidia_agx_xavier_32.4.3_dmesg.txt (68.8 KB) tegra194-p2822-disp.dtsi (3.1 KB) edid.c (26.5 KB)

Sharing my kernel log dmesg, and files where I made changes. can you suggest anything, Still my DP is not up, not getting any output in AUX channels as well when we probe it

Looks like hpd and edid read are still needed and cannot be disabled. Thus, please just follow our OEM design guide for your hardware.

BTW, do you ever change the pinmux setting? If not, verify your SOR0 first since it was original for DP, no pinmux should be changed.

hey sorry for thsi, how to enable use_fallback?
should I make it to true here?: bool use_fallback = false;

int tegra_edid_get_monspecs(struct tegra_edid *edid, struct fb_monspecs *specs)
int i;
int j;
int ret;
int extension_blocks;
struct tegra_edid_pvt *new_data, *old_data;
u8 checksum = 0;
u8 *data;
bool use_fallback = false;

new_data = vzalloc(SZ_32K + sizeof(struct tegra_edid_pvt));
if (!new_data)
	return -ENOMEM;


if (edid->errors & EDID_ERRORS_READ_FAILED)
	use_fallback = true;
edid->errors = 0;

data = new_data->dc_edid.buf;

Yes, make it true at that line.

1 Like

Hi, we are not yet have success with DP yet.

We are not using DP over type-c Instead, we are using standard DP connector for DP0 (SOR0).

We saw something like this in nvidia site:

Seamless Display on DP (over USB-C)

Seamless Display (display initialization by the bootloader) is not enabled on DP for NVIDA® Jetson AGX Xavier™ in the current release.

This is because for DP, the bootloader display polls for at most 1 msec by default when trying to detect if HPD has been asserted by the sink. Different Type-C downstream devices that you may connect to the Type-C ports on Galen (cables, adapters, hubs, etc.) may incur different amounts of latency before they trigger the handshake process needed to drive DP over Type-C. The delay is non-deterministic, so adding a loop to poll the HPD status could increase boot time. Seamless display has been disabled on DP to avoid inconsistent behavior.

in below link : Tegra Linux Driver

So is there any way to edit or update the driver to support to have seamless DP display support since we are using standard DP connector?

This feature has nothing to do with your current issue. Remove the nvidia,typec-port = /bits/ 8 <0>; will be sufficient for the normal DP connector.

You are not the first user here asking how to use general DP connector instead of typeC.

Hey, I have removed nvidia,typec-port = /bits/ 8 <0>; already and tried. anything else do I need to change or look into? any how I will compare the hardware OEM design guide.

And yes I missed to update, no pinmux changed yet.


I have tried with some of the options given by you and some other forum discussion, still my DisplayPort is not up.
I am able to read the EDID with command. see boot log, dmesg log and debug logs in attachmentfresh_boot_logs_with_dp_connected_02172021.txt (168.4 KB)

tried below options,

  1. Prepare a known 256byte EDID.
  2. set use_fallback = true; in tegra_edid_get_monspecs() under edid.c.
  3. fill in the known EDID to default_720p_edid[256].
  4. removing hardware/nvidia/platform/t19x/galen/kernel-dts/common/tegra194-p2888-0001-p2822-0000-common.dtsi: nvidia,typec-port = /bits/ 8 <0>;
  5. in DP.c removed below lines of code,
if (dc->edid->errors) {
	return (mode->xres == 640 && mode->yres == 480)
		 ? true : false;
```  as per this link

but I see some errors in the boot log shared here, and DisplyaPort is not getting up. please guide me into right path

Are you sure the hardware design match the design guide?

My suggestion is you can firstly leverage the port which is defined as DP in devkit and use that to verify your hardware.

For example, you only swap 2 ports on your board, it means there is at least one DP port that should work if your hardware design is correct. And please remember to remove the “nvidia,typec-port = /bits/ 8 <0>;” for that case.

We have verified the design and it as per design guide, also I have remember to remove the “nvidia,typec-port = /bits/ 8 <0>;”

should these errors are fine?
[ 1.604697] tegradc 15200000.nvdisplay: dp: aux write got error (0x10000100)
[ 1.604732] tegradc 15200000.nvdisplay: dp: Failed for I2C write addr:80, size:1, stat:0x10000100
[ 1.629514] tegradc 15200000.nvdisplay: dp: aux write got error (0x10000100)
[ 1.629546] tegradc 15200000.nvdisplay: dp: Failed to write DPCD data. CMD 0x600, Status 0x10000100
[ 1.634913] tegradc 15200000.nvdisplay: dp: aux write got error (0x10000100)
[ 1.634945] tegradc 15200000.nvdisplay: dp: Failed to write DPCD data. CMD 0x600, Status 0x10000100
[ 1.640309] tegradc 15200000.nvdisplay: dp: aux write got error (0x10000100)
[ 1.640338] tegradc 15200000.nvdisplay: dp: Failed to write DPCD data. CMD 0x600, Status 0x10000100
[ 1.645667] tegradc 15200000.nvdisplay: dp: aux write got error (0x10000100)
[ 1.645708] tegradc 15200000.nvdisplay: dp: Failed to write DPCD data. CMD 0x600, Status 0x10000100

With this we have seen the display up once for few seconds and went off and never up again with same setting and DSP.

These errors are not fine. Is that port a DP port on devkit?

As I said, use the DP port from devkit first to verify your hardware.


This port and details are from our custom board and not from devkit, Seems I do not have a devkit right now, I will check if I can do this exercise and look more from Hardware side.


I understand this is your board.

What I am trying to say is:

you are also using 2 DP + 1 HDMI on your board from comment #1, right?

If so, it means at least 1 DP port here does not need to change too much software part (dts/pinmux). Use that DP port to debug your dp hardware design first. Because the software on this port is already verified on every devkit. No need you to buy a devkit to verify that again.
If even the configuration on this port cannot work on your board, it means not a software problem.

Hi we have tried with AGX devkit and unfortunately DP does not work in it as well, HDMI is working. I have flashed Image into 32GB module using SDK manager/jetpack.

We did not had a type C DP cable and used a type c to normal DP converter, tried both the ports on devkit. I will try what you said earlier to check with one DP with our board as well.

However DP is working with our Nano devkit. Any suggestion?


This is not needed. No need to verify typeC - DP on the devkit. This should work.
If it does not, change the cable or change to other monitors. But this is not what we should focus now…

yes cable and Monitor we have is working as we have checked with other modules and PCs, checked same monitor and cable with Nano devkit and it is working.

I have a doubt here , We can see that Link training is passing for DP from dmsg log , is there any possibilities that DP will not work once Link training is passed?

You didn’t share the full log so far so I cannot tell what is going on.

Hi, you can refer this log file