Hi! Does Jetson Nano Linux 4 Tegra support write to EDID via I2C?
Are you trying to artificially provide an EDID? In normal operation all HDMI use the i2c protocol on the DDC wire. The expected operation is that hot plug is detected, and this will trigger the HDMI to provide power to the monitor’s i2c hardware, followed by a query of that EDID (it’s really EDID2 now) data. Although the GPU driver of Jetsons won’t allow setup without EDID, there is a fallback mode. That mode is set in the kernel, so if you just want a default fallback mode, look at “sources/kernel/nvidia/drivers/video/tegra/dc/edid.c”.
We have a microdisplay that controlled over EDID table. So I must write to EDID table a value to control the microdisplay.
I can’t give the details, but what you’d have to do is have hot plug detect trigger powering the i2c (although technically you could always power the i2c which has the EDID), which is normal when plugging in HDMI, and then trigger your i2c responding to the DDC wire.
If you go to the pin diagram of HDMI here:
https://en.wikipedia.org/wiki/HDMI
Notice that pins 15 and 16 are i2c. You’d have to check and verify, but I think it is a 3.3V level (with some pull-up or pull-down resistance). I don’t know if the hot plug detect is active high or active low, but you could throw an i2c protocol analyzer on in combination with watching the hot plug detect to verify.
Do note that Jetsons don’t allow quite as wide of a range of EDID entries as a desktop PC, so make sure your EDID is supported.
EDID supported. There is image in microdisplay. Works fine.
test-user@testuser-desktop:~$ sudo cat /sys/kernel/debug/tegradc.0/edid
00 ff ff ff ff ff ff 00 06 8f 07 11 01 00 00 00
17 11 01 03 80 0c 09 78 0a 1e ac 98 59 56 85 28
29 50 54 01 00 00 01 01 01 01 01 01 01 01 00 00
01 01 01 01 01 01 a0 0f 20 00 31 58 1c 20 28 80
14 00 81 60 00 00 00 18 01 1d 80 18 71 1c 16 20
58 2c 25 00 81 49 00 00 00 9e 00 00 00 fc 00 56
41 2d 31 38 30 39 41 0a 20 20 20 20 00 00 00 fd
00 17 3d 0d 2e 11 00 0a 20 20 20 20 20 20 01 e3
02 03 34 71 4d 82 05 04 01 10 11 14 13 1f 06 15
03 12 35 0f 7f 07 17 1f 38 1f 07 30 2f 07 72 3f
7f 72 57 7f 00 37 7f 72 83 4f 00 00 67 03 0c 00
10 00 88 2d 00 00 00 ff 00 0a 20 20 20 20 20 20
20 20 20 20 20 20 00 00 00 ff 00 0a 20 20 20 20
20 20 20 20 20 20 20 20 00 00 00 ff 00 0a 20 20
20 20 20 20 20 20 20 20 20 20 00 00 00 00 00 00
a2 3a 00 00 00 00 00 00 00 00 00 00 00 00 00 fe
But when I try to detect I2C:
test-user@testuser-desktop:~$ sudo i2cdetect -l
[sudo] password for test-user:
i2c-3 i2c 7000c700.i2c I2C adapter
i2c-1 i2c 7000c400.i2c I2C adapter
i2c-101 i2c tegradc.1 I2C adapter
i2c-8 i2c i2c-6-mux (chan_id 1) I2C adapter
i2c-6 i2c Tegra I2C adapter I2C adapter
i2c-4 i2c 7000d000.i2c I2C adapter
i2c-2 i2c 7000c500.i2c I2C adapter
i2c-0 i2c 7000c000.i2c I2C adapter
i2c-7 i2c i2c-6-mux (chan_id 0) I2C adapter
i2c-5 i2c 7000d100.i2c I2C adapter
I thought: may be i2c-101 is what I have searched? But i2cdetect doesn’t see anything:
test-user@testuser-desktop:~$ sudo i2cdetect -y -a 101
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
NVIDIA would have to answer since I do not know those details. I don’t know if that is the correct bus. One detail though is that often an unused i2c is powered down to save power, and so it is possible (I don’t know if this really happens) that once hot plug detect is done, the bus shuts down and you might not be able to read this if that bus is directly from the DDC.
The other detail I will suggest while debugging is to add “ModeDebug” to the “/etc/X11/xorg.conf” to get verbose logging (the driver will tell you about EDID and about each mode if EDID is found):
Section "Device"
Option "ModeDebug"
...
NVIDIA should be able to tell you if that i2cdetect is correct, but I do not know (my recollection though is that it is at address 0x50, but it depends on the bus and perhaps customization).
should be related to this
1 Like
The Xorg.0.log verifies that the EDID is received, has a valid checksum, and has many modes which are within the range of the GPU/driver. This does imply that a monitor was detected and queried. If for some reason you are experimenting and the i2c is not powered, this would still fail; the “/sys” echo which @WayneWWW mentioned would take care of this (but I don’t know if enabling this is enough to trigger a query, but it is definitely required for an i2c response).
In case it helps later, here is a recap of the modes making up the valid mode pool:
[ 5.999] (II) NVIDIA(GPU-0): --- Modes in ModePool for ASTRO DESIGN, INC. VA-1809A (DFP-0) ---
[ 5.999] (II) NVIDIA(GPU-0): "nvidia-auto-select" : 800 x 600 @ 60.3 Hz (from: EDID, Detailed)
[ 5.999] (II) NVIDIA(GPU-0): "1920x1080" : 1920 x 1080 @ 60.0 Hz (from: EDID, CEA)
[ 5.999] (II) NVIDIA(GPU-0): "1920x1080_60" : 1920 x 1080 @ 60.0 Hz (from: EDID, CEA)
[ 6.000] (II) NVIDIA(GPU-0): "1920x1080_60_0" : 1920 x 1080 @ 59.9 Hz (from: EDID, CEA)
[ 6.000] (II) NVIDIA(GPU-0): "1920x1080_50" : 1920 x 1080 @ 50.0 Hz (from: EDID, CEA)
[ 6.000] (II) NVIDIA(GPU-0): "1280x720" : 1280 x 720 @ 60.0 Hz (from: EDID, CEA)
[ 6.000] (II) NVIDIA(GPU-0): "1280x720_60" : 1280 x 720 @ 60.0 Hz (from: EDID, CEA)
[ 6.000] (II) NVIDIA(GPU-0): "1280x720_60_0" : 1280 x 720 @ 59.9 Hz (from: EDID, CEA)
[ 6.000] (II) NVIDIA(GPU-0): "1280x720_50" : 1280 x 720 @ 50.0 Hz (from: EDID, CEA)
[ 6.000] (II) NVIDIA(GPU-0): "800x600" : 800 x 600 @ 60.3 Hz (from: EDID, Detailed)
[ 6.000] (II) NVIDIA(GPU-0): "800x600_60" : 800 x 600 @ 60.3 Hz (from: EDID, Detailed)
[ 6.000] (II) NVIDIA(GPU-0): "800x600_60_0" : 800 x 600 @ 60.3 Hz (from: EDID)
[ 6.000] (II) NVIDIA(GPU-0): "720x576" : 720 x 576 @ 50.0 Hz (from: EDID, CEA)
[ 6.000] (II) NVIDIA(GPU-0): "720x576_50" : 720 x 576 @ 50.0 Hz (from: EDID, CEA)
[ 6.000] (II) NVIDIA(GPU-0): "720x480" : 720 x 480 @ 59.9 Hz (from: EDID, CEA)
[ 6.000] (II) NVIDIA(GPU-0): "720x480_60" : 720 x 480 @ 59.9 Hz (from: EDID, CEA)
[ 6.000] (II) NVIDIA(GPU-0): "640x480" : 640 x 480 @ 59.9 Hz (from: EDID, CEA)
[ 6.000] (II) NVIDIA(GPU-0): "640x480_60" : 640 x 480 @ 59.9 Hz (from: EDID, CEA)
[ 6.000] (II) NVIDIA(GPU-0): "640x350" : 640 x 350 @ 85.1 Hz (from: EDID)
[ 6.000] (II) NVIDIA(GPU-0): "640x350_85" : 640 x 350 @ 85.1 Hz (from: EDID)
[ 6.000] (II) NVIDIA(GPU-0): --- End of ModePool for ASTRO DESIGN, INC. VA-1809A (DFP-0): ---
Incidentally, what do you see from this:
sudo -s
cd /sys
find . -name 'edid'
(this populates from the EDID query in the logs; or more precisely, this is created and makes the Xorg log able to examine modes for a mode pool)
I did
sudo sh -c "echo 1 > /sys/kernel/debug/tegra_hdmi/ddc_power_toggle"
And everything works fine! Example:
test-user@testuser-desktop:~$ i2cdump 3 0x50
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-3, address 0x50, mode byte
Continue? [Y/n] Y
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 ff ff ff ff ff ff 00 06 8f 07 11 01 00 00 00 ........?????...
10: 17 11 01 03 80 0c 09 78 0a 1e ac 98 59 56 85 28 ???????x????YV?(
20: 29 50 54 01 00 00 01 01 01 01 01 01 01 01 00 00 )PT?..????????..
30: 01 01 01 01 01 01 a0 0f 20 00 31 58 1c 20 28 80 ???????? .1X? (?
40: 14 00 81 60 00 00 00 18 01 1d 80 18 71 1c 16 20 ?.?`...?????q??
50: 58 2c 25 00 81 49 00 00 00 9e 00 00 00 fc 00 56 X,%.?I...?...?.V
60: 41 2d 31 38 30 39 41 0a 20 20 20 20 00 00 00 fd A-1809A? ...?
70: 00 17 3d 0d 2e 11 00 0a 20 20 20 20 20 20 01 e3 .?=?.?.? ??
80: 02 03 34 71 4d 82 05 04 01 10 11 14 13 1f 06 15 ??4qM???????????
90: 03 12 35 0f 7f 07 17 1f 38 1f 07 30 2f 07 72 3f ??5?????8??0/?r?
a0: 7f 72 57 7f 00 37 7f 72 83 4f 00 00 67 03 0c 00 ?rW?.7?r?O..g??.
b0: 10 00 88 2d 00 00 00 ff 00 0a 20 20 20 20 20 20 ?.?-.....?
c0: 20 20 20 20 20 20 00 00 00 ff 00 0a 20 20 20 20 .....?
d0: 20 20 20 20 20 20 20 20 00 00 00 ff 00 0a 20 20 .....?
e0: 20 20 20 20 20 20 20 20 20 20 00 00 00 00 00 00 ......
f0: a2 3a 00 00 00 00 00 00 00 00 00 00 00 00 00 da ?:.............?
Reading a byte <0xF0>:
test-user@testuser-desktop:~$ i2cget -y 3 0x50 0xf0
0xa2
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.