UHD 60 Issue

Jetson TX1 development board doesn’t list 3840x2160@60 Hz when LG TV with upto 4096x2160@60 is connected.
60 Hz mode is not displayed because of a code in tegra_hdmi_fb_mode_filter() in drivers/video/tegra/dc/hdmi2.0.c

if (tegra_hdmi_mode_min_tmds_rate(mode) / 1000 >= 340 &&
(!tegra_edid_is_hfvsdb_present(hdmi->edid) ||
!tegra_edid_is_scdc_present(hdmi->edid)))
return false;

If this check is commented, UHD@60 is listed when checked with xrandr and TV also can set 3840x2160@60 Hz. But if we use xrandr to change the mode to 3840x2160@30 or 24, it fails and TV blanks off and displays ‘no signal’.

To recover we have to unplug and plug back HDMI cable and this even sets the mode to 3840x2160@30 or 24 as the case may be.

The code says this for faulty EDID:
/*
* There are currently many TVs in the market that actually do NOT support
* 4k@60fps 4:4:4 (594 MHz), (especially on the HDCP 2.2 ports), but
* advertise it in the DTD block in their EDIDs. The workaround for this port
* is to disable the 594 MHz mode if no HF-VSDB is present or if no SCDC
* support is indicated

But in the driver log there is no error message.

Is there a solution to this issue?

If the TV is connected to the JTX1, what is the content of this file:

/sys/kernel/debug/tegradc.1/edid

Content of
/sys/kernel/debug/tegradc.1/edid

00 ff ff ff ff ff ff 00 1e 6d 01 00 01 01 01 01
01 1a 01 03 80 a0 5a 78 0a ee 91 a3 54 4c 99 26
0f 50 54 a1 08 00 31 40 45 40 61 40 71 40 81 80
01 01 01 01 01 01 08 e8 00 30 f2 70 5a 80 b0 58
8a 00 40 84 63 00 00 1e 02 3a 80 18 71 38 2d 40
58 2c 45 00 40 84 63 00 00 1e 00 00 00 fd 00 3a
3e 1e 88 3c 00 0a 20 20 20 20 20 20 00 00 00 fc
00 4c 47 20 54 56 0a 20 20 20 20 20 20 20 01 9f
02 03 4e f1 54 5d 10 1f 04 13 05 14 03 02 12 20
21 22 15 01 5e 5f 62 63 64 29 3d 06 c0 15 07 50
09 57 07 6e 03 0c 00 10 00 b8 3c 20 00 80 01 02
03 04 e2 00 cf e3 06 05 01 e5 0e 60 65 61 66 ee
01 46 d0 00 24 0b 75 00 a8 55 4e 9d 27 0b 01 1d
80 18 71 1c 16 20 58 2c 25 00 40 84 63 00 00 9e
66 21 50 b0 51 00 1b 30 40 70 36 00 40 84 63 00
00 1e 00 00 00 00 00 00 00 00 00 00 00 00 00 f5

That hex data from that file is a description of valid modes which the monitor itself is claiming to be true. You could use “get-edid | parse-edid” or “get-edid | edid-decode” (packages “read-edid” and “edid-decode”) to see what the Jetson thinks of this monitor, or you can paste this directly in this web site’s EDID decoder:
http://www.edidreader.com/

Using that web URL and pasting the hex data into that, click on the “Video Data Block”. You’ll see that although 3840x2160 is supported, the TV itself says 60Hz is not. There are other places where 3840x2160 might be listed, but I can’t verify that any of those work with 60Hz.

What is the output from these directly on the Jetson?

sudo get-edid | parse-edid
# or:
sudo get-edid | edid-decode

When get-edid is used on the board:

read-edid version 3.0.1. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 1
No EDID on bus 3
No EDID on bus 4
No EDID on bus 5
No EDID on bus 6
1 potential busses found: 2
Bus 2 doesn't really have an EDID...
Couldn't find an accessible EDID on this computer.
I'm sorry nothing was successful. Maybe try some other arguments
if you played with them, or send an email to Matthew Kern <pyrophobicman@gmail.com>.
Partial Read... Try again

Looks like I2C times out.
This is from dmesg:

2c 7000c000.i2c: no acknowledge from address 0x50
[ 1977.072496] tegra-i2c 7000c400.i2c: no acknowledge from address 0x50
[ 1978.069288] tegra-i2c 7000c700.i2c: --- register dump for debugging ----
[ 1978.076164] tegra-i2c 7000c700.i2c: I2C_CNFG - 0x22c00
[ 1978.081840] tegra-i2c 7000c700.i2c: I2C_PACKET_TRANSFER_STATUS - 0x10001
[ 1978.091105] tegra-i2c 7000c700.i2c: I2C_FIFO_CONTROL - 0xe0
[ 1978.096681] tegra-i2c 7000c700.i2c: I2C_FIFO_STATUS - 0x800040
[ 1978.102534] tegra-i2c 7000c700.i2c: I2C_INT_MASK - 0xed
[ 1978.107756] tegra-i2c 7000c700.i2c: I2C_INT_STATUS - 0x0
[ 1978.113152] tegra-i2c 7000c700.i2c: msg->len - 1
[ 1978.117831] tegra-i2c 7000c700.i2c: is_msg_write - 1
[ 1978.122908] tegra-i2c 7000c700.i2c: next_msg->len - 1
[ 1978.127957] tegra-i2c 7000c700.i2c: is_next_msg_write - 0
[ 1978.133365] tegra-i2c 7000c700.i2c: buf_remaining - 1
[ 1978.138427] tegra-i2c 7000c700.i2c: i2c transfer timed out, addr 0x0050, data 0x00
[ 1978.146226] tegra-i2c 7000d000.i2c: no acknowledge from address 0x50
[ 1979.138953] tegra-i2c 7000d100.i2c: --- register dump for debugging ----
[ 1979.145825] tegra-i2c 7000d100.i2c: I2C_CNFG - 0x22c00
[ 1979.151345] tegra-i2c 7000d100.i2c: I2C_PACKET_TRANSFER_STATUS - 0x10001
[ 1979.158170] tegra-i2c 7000d100.i2c: I2C_FIFO_CONTROL - 0xe0
[ 1979.164429] tegra-i2c 7000d100.i2c: I2C_FIFO_STATUS - 0x800040
[ 1979.170322] tegra-i2c 7000d100.i2c: I2C_INT_MASK - 0xed
[ 1979.175540] tegra-i2c 7000d100.i2c: I2C_INT_STATUS - 0x0
[ 1979.180863] tegra-i2c 7000d100.i2c: msg->len - 1
[ 1979.185476] tegra-i2c 7000d100.i2c: is_msg_write - 1
[ 1979.190447] tegra-i2c 7000d100.i2c: next_msg->len - 1
[ 1979.195532] tegra-i2c 7000d100.i2c: is_next_msg_write - 0
[ 1979.200942] tegra-i2c 7000d100.i2c: buf_remaining - 1
[ 1979.206011] tegra-i2c 7000d100.i2c: i2c transfer timed out, addr 0x0050, data 0x00
[ 1979.214949] tegra-vii2c 546c0000.i2c: no acknowledge from address 0x50a

The raw hex data is independent of any programs parsing it, and shows up with proper checksum on that EDID web URL. Which version of the read-edid package do you have?

sudo dpkg --list read-edid

Right now version 3.0.2-1 is on the updated version on L4T R24.2 release; very recently someone with an issue reported upgrading from 3.0.1 to 3.0.2 solved a similar issue. I’m wondering if this would fix that issue for you as well. The “/sys” hex data would not exist if i2c hardware itself were the issue, so I suspect this is software related (unfortunately that doesn’t narrow it down much).

Regardless, if software can’t read EDID, then video would rely on defaults (and just because get-edid doesn’t read EDID does not mean something else can or can’t read EDID, though it is increasingly likely other software would also fail). Should EDID be properly read the data still indicates the desired 3840x2160@60 could not be achieved. The slower scan rates under 3840x2160 would likely succeed if EDID were parsed at the correct place (see the URL’s “Block 1 → CEA Data Block → Video Data Block”, which indicates 24Hz and 25Hz should work).

From edidreader.com:
“Block 0 → Standard Timing Information → Descriptor 1” shows 3840x2160 to use pixel clock of 594 MHz.

Deriving from this:
PixelClk / (Hactive+Hblank)x(Vactive+Vblank)
= 594000000 / ((3840+560) x (2160+90))
= 60 Hz

Doesn’t this say the TV supports UHD@60 ?
Please correct me if I’m wrong.

If the following code in hdmi2.0.c is commented mode list shows 3840x2160@60 and we can set that mode.

if (tegra_hdmi_mode_min_tmds_rate(mode) / 1000 >= 340 &&
(!tegra_edid_is_hfvsdb_present(hdmi->edid) ||
!tegra_edid_is_scdc_present(hdmi->edid)))
return false;

TV blanks off and displays ‘no signal’ when mode is switched from 3840x2160@60 to 3840x2160@30 or 3840x2160@24 or 1920x1080@60.

This is speculation about what I think is going on…I won’t guarantee it…

There are two parts of EDID data to consider. One is the raw data regarding the monitor’s characteristics, including the “detailed timing”, along with modes the data itself lists based on this…the “timing bitmap”.

The raw data could be used to calculate a timing bitmap, or the timing bitmap could be used directly on the assumption that the monitor’s EDID is correctly programmed with that information in a way which is consistent with the raw data. If the Jetson’s software calculates the timing bitmaps rather than using the provided bitmaps directly, then the Jetson would be second guessing the existing timing bitmaps. Why do this if the monitor already has this information and calculation is not required? I suspect the Jetson is taking the monitor for its word on what timing bitmaps are there, and does not calculate this. It seems that even if the value you want is possible through direct calculation, EDID left this out.

One possibility as to why this value was left out of timing bitmap is that a manufacturer may want to blacklist some of the higher end settings. Even though the signal timings work logically, it is quite possible this mode would not be allowed because of damage to the monitor. There is a possibility that even if you were to bypass something and provide the desired 60 fps the monitor itself may be programmed to explicitly ignore this. I can only speculate that some software vendors calculate the timing bitmaps and others use the timing bitmaps directly without calculating it…really though, if the monitor supports a given mode, then the timing bitmap should show it. Making it work without this would be an EDID quirk workaround (notice the email address listed with the read-edid when it says it can’t find a monitor…quirk workarounds might be a good reason to send the information to that email address).

Since the read-edid is failing, yet EDID data is available in “/sys”, I’d suspect something parsing the EDID data may not know what to do if timings suggest a mode is available while timing bitmaps disagrees. You’d probably need to run a debug version of read-edid in gdb with that exact monitor attached to see if this is truly the case. I don’t see a debug package for read-edid, so you’d have to compile your own read-edid with debug symbols to do this.