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 &&
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:
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:
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
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 <email@example.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).
“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 &&
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.