2048x1536 eDP display on TX1

I have a Samsung eDP panel and a custom display expansion header PCB. The EDID on the panel specifies H_SYNC_WIDTH = 5, and H_BACK_PORCH = 160 - 150 - 5 = 5. For an eDP panel, H_REF_TO_SYNC is always 1.
Therefore H_REF_TO_SYNC + H_SYNC_WIDTH + H_BACK_PORCH == 11 on my system. The display fails to work because of this check in kernel/display/drivers/video/tegra/dc/mode.c at line 124.

Can someone tell me what this check is for, and why a panel like this one should not be supported?

/* Constraint 1: H_REF_TO_SYNC + H_SYNC_WIDTH + H_BACK_PORCH > 11. */
CHK(mode->h_ref_to_sync + mode->h_sync_width +
    mode->h_back_porch <= 11,

The console outputs:

[    2.993527] tegradc tegradc.0: nominal-pclk:37037000
parent:37036669 div:1.0 pclk:37036669 36666630~40370330
[    2.997027] H_REF_TO_SYNC + H_SYNC_WIDTH + H_BACK_PORCH <= 11
[    2.997034] tegradc tegradc.0: Display timing doesn't meet restrictions.

The panel EDID contains the following. I have attached the raw EDID to this post.

Pixel Clock: 205.21MHz
Horizontal Active: 2048
Horizontal Blanking: 160
Vertical Active: 1536
Vertical Blanking: 13
Horizontal Sync Offset: 150
Horizontal Sync Pulse: 5
Vertical Sync Offset: 3
Vertical Sync Pulse: 1
Horizontal Display Size: 197
Vertical Display Size: 148
Horizontal Border: 0
Vertical Border: 0
Interlaced: false
Stereo Mode: 0
Sync Type: 3


edid.txt (648 Bytes)

Hi Undertow10

Your H_REF_TO_SYNC should be 2 to avoid the error.

Could you check how the value of h_ref_to_sync changes in “check_mode_timings” in mode.c?

Hi Wayne,

Thanks for the reply. The code just before the call to check_ref_to_sync() sets h_ref_to_sync and v_ref_to_sync to 1. I have confirmed dc->out->type == TEGRA_DC_OUT_DP and it does reach this code.

if (dc->out->type == TEGRA_DC_OUT_DP) {
	mode->h_ref_to_sync = 1;
	mode->v_ref_to_sync = 1;

if (!check_ref_to_sync(mode, verbose)) {
	if (verbose)
			"Display timing doesn't meet restrictions.\n");
	return false;

Hi Undertow10,

Could you try to modify the value to 2 first and see if it can work?
Your monitor seems use a preferred mode and I don’t see it in the CEA mode lists. Maybe this is the reason our driver rejects it.

We do have some topics that old monitors have trouble in mode selection.

if (dc->out->type == TEGRA_DC_OUT_DP) {
	mode->h_ref_to_sync = 2;  //Modify this 
	mode->v_ref_to_sync = 1;

Hi Wayne,

Yes, this fixes the problem. My display works now. Thanks for your help!

I did have one other question. I noticed in your dual monitor patch (https://devtalk.nvidia.com/default/topic/1023387/jetson-tx1/how-to-make-a-kernel-with-dual-diplay-on-r28-1/post/5217743/#5217743) that you are expecting your display board id to be BOARD_E1824.

I have tried a lot of things, but can’t seem to get the board info to read properly:

[    0.520663] display board info: id 0xffff, fab 0x0

I first confirmed that board_info_path == “/chosen/display-board”. I added that to my DTS file. This is what my decompiled final DTB file shows for the chosen node:

chosen {
		fastboot-instructions = "Tap on power button to navigate menu options.\nHold down power button for 2 sec and release for selecting an option\n";
		stdout-path = "/serial@70006000";

		bootloader {

		display-board {
			id = <0x720>;

How can I get the code to dynamically pull the correct board ID from my DTS file without hard-coding it in board-panel.c?



The board id is define in


<board type="display" id="1824" sku="0x123"/>

E1824 is a name of our internal board for eDP panel.

Hi Wayne,

When I use the screen in normal landscape orientation, I get a good refresh rate. Now I am trying to rotate the orientation of the eDP screen, and the refresh rate gets very slow. In either orientation, xrandr shows:

Screen 0: minimum 8 x 8, current 3456 x 2048, maximum 16384 x 16384
DP-0 connected primary 1536x2048+1920+0 left (normal left inverted right x axis y axis) 200mm x 150mm
   720x480       82.22 +
   3840x2160      4.17  
   2048x1536     11.60*

Some of this info seems wrong. Somehow I get a good refresh rate (~60hz?) as long as the rotation is “normal” not “left”.

xrandr --verbose shows the clock rate on all three of those resolutions is 37.037Mhz, which is suspisciously the same as the PCLK rate in the vga mode struct you suggested to modify:

.pixclock = KHZ2PICOS(37037)

Why is xrandr showing the slow refresh mode, but still working fine in normal rotation, but then actually using the slow refresh mode when rotated left?

Hi Undertow10,

Do you mean after using xrandr to rotate the pixel clock will drop?

Either using xrandr or the display settings GUI to rotate causes the refresh rate to go down, presumably to the 11.60 Hz listed in the xrandr printout.

I think the real problem is that my display supports a pixel clock of 205.212 MHz, but xrandr only shows modes with a 37.037 MHz clock rate. However, somehow it runs at a faster refresh rate when not rotated.

Sounds like a bug. Do other kinds of display also have same issue? How do you confirm the current clock?

I have not been able to confirm with another display, nor have I been able to confirm the clock rate yet. I just see the framerate is noticeably slower (11 Hz seems plausible) once rotated. I will try to confirm the clock rate somehow tomorrow.


I want to convert from eDP connector to DP connector.

Which type of cable should I buy?

Hi Wayne,

Just a quick update. I was able to apply the patch from here: https://devtalk.nvidia.com/default/topic/1024289/read-custom-edid/?offset=8

This seems to have solved the problem. I should have done this earlier per your recommendation, sorry. Xrandr now shows only the resolution from the EDID, which is 2048x1536 @ 60 Hz, not the ones that were manually specified in the panel dts file.

Thanks for your help!


Looks like it is a framebuffer mode update issue as the topic you pasted. I didn’t notice that Xrandr rotate also triggers the update process in driver.

Thanks for info.


I’m bringing up a new carrier board now, and attempting to get eDP working. I think the problem is that our new carrier board does not have a TCA9539 GPIO expander to enable vdd_ds_1v8. Is there a way to bypass this check or tell the DTS file there is no regulator / load switch?


[    4.226457] tegradc tegradc.0: fb registered
[    4.235418] vdd_ds_1v8 regulator get failed
[    4.240989] edp regulator get failed
[    4.248175] tegradc tegradc.0: nominal-pclk:37037000 parent:37036669 div:1.0 pclk:37036669 36666630~40370330
[    4.275745] dp lt: state 0 (Reset), hpd 1, pending_lt_evt 1
[    4.282855] dp lt: switching from state 0 (Reset) to state 0 (Reset)
[    4.290757] dp lt: state 0 (Reset), hpd 1, pending_lt_evt 0
[    4.299126] dp lt: switching from state 0 (Reset) to state 2 (clock recovery)
[    4.307813] dp lt: state 2 (clock recovery), hpd 1, pending_lt_evt 0
[    4.315975] dp lt: config: lane 0: vs level: 0, pe level: 0, pc2 level: 0
[    4.324316] dp lt: config: lane 1: vs level: 0, pe level: 0, pc2 level: 0
[    4.332603] dp lt: config: lane 2: vs level: 0, pe level: 0, pc2 level: 0
[    4.340859] dp lt: config: lane 3: vs level: 0, pe level: 0, pc2 level: 0
[    4.350340] dp lt: CR done
[    4.354536] dp lt: switching from state 2 (clock recovery) to state 3 (channel equalization)
[    4.366234] dp lt: state 3 (channel equalization), hpd 1, pending_lt_evt 0
[    4.377876] dp lt: CE done
[    4.382445] dp lt: switching from state 3 (channel equalization) to state 5 (link training pass)

Please just comment out those regulator checks in edp panel driver if you don’t need it.