I2c adapter not working to read EDID from screens attached via MST hub [gt630] [331.20]

Hi,
Our company uses NVidia cards in an embedded system and has a requirement to detect when someone unplugs a screen. To do this we continuously read the I2C ports exported by the driver to the Linux kernel, as documented in Appendix F. i2c Bus Support , using code like this:

char buff[4];
	int r;
	ioctl(fd, I2C_SLAVE, 0x50);
	r = read(fd, buff, 1);
	return r == 1;	//successful

fd in this case is e.g. /dev/i2c-0, /dev/i2c-1, as created by the driver when X windows starts. If a read does not get a byte we know the screen is unplugged.

This has been working for years but doesn’t work on our latest hardware configuration which is a single GT630 driving three screens: the DVI output drives one screen, and the DP output drives screens 2 and 3 via an MST hub.

Screens connected to the DVI output can always be read.
Screens connected directly to the DP output (including via a DP->DVI converter) can be read.
Screens connected to the DP output via an MST hub cannot be read.

We know the EDID data is getting through because in all situations, X windows correctly configures the screens (and we can see the screens’ correct EDID data in the X log). The problem is that if we try to read the EDID via the i2c ports of screens that are attached via the hub, we get read errors.

Edit 27/11: Now adding nvidia-bug-report.StandardPCUbuntu1204LTS.log.gz. This is the same fault but reproduced on a standard PC (Dell OptiPlex 755) running a common Linux distro (Ubuntu 12.04LTS 32bit). Once again all 3 screens were configured by X windows but we can’t read the i2c for the screens connected via MST hub.

Edit 29/11: Add link to Appendix F. i2c Bus Support.
[This file was removed because it was flagged as potentially malicious] (45.9 KB)
nvidia-bug-report.StandardPCUbuntu1204LTS.log.gz (142 KB)

To rule out our reading code as the source of the problem we tried with the official I2C tools which are i2cdetect and i2cdump. i2cdetect correctly detects the adapters after X windows starts as does our code:

# i2cdetect -l
i2c-0   i2c             NVIDIA i2c adapter 0 at 1:00.0          Algorithm unavailable
i2c-1   i2c             NVIDIA i2c adapter 1 at 1:00.0          Algorithm unavailable
i2c-2   i2c             NVIDIA i2c adapter 6 at 1:00.0          Algorithm unavailable
i2c-3   i2c             NVIDIA i2c adapter 10 at 1:00.0         Algorithm unavailable

Like our code i2cdump can only read valid EDID for the screen attached to the DVI output, the others read all 0xFF:

-bash-4.2# i2cdump -y 0 80
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX

Example of reading from screen on the DVI output:

-bash-4.2# i2cdump -y 1 80
No size specified (using byte-data access)
     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 2e 9e 22 00 01 00 00 00    .........?".?...
10: 14 13 01 03 80 31 20 78 ef 1e 05 a3 54 4c 99 26    ?????1 x????TL?&
20: 0f 50 54 a5 4b 00 b3 00 81 80 61 40 01 01 31 40    ?PT?K.?.??a@??1@
30: 01 01 01 01 01 01 6c 39 90 40 62 1a 25 40 68 b8    ??????l9?@b?%@h?
40: 13 00 ee 40 11 00 00 1a 95 29 a0 d0 51 84 20 30    ?.?@?..??)??Q? 0
50: 98 50 13 00 ee 40 11 00 00 1c 30 2a 00 98 51 00    ?P?.?@?..?0*.?Q.
60: 2a 40 30 70 13 00 ee 40 11 00 00 1e 00 00 00 fc    *@0p?.?@?..?...?
70: 00 4b 54 4c 32 32 30 53 0a 0a 0a 0a 0a 0a 00 cc    .KTL220S??????.?
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX

We’ve reproduced this on:

  • kernels 2.6.31, 3.8.0 and 3.9.2
  • driver versions 319.32 and 331.20

DaveGambler, Thanks for reporting this issue.

  • Is any previous driver working on your setup?
  • Please share make, model and screenshot of MST hub you are using?
  • Please provide step by steps reproduction steps with single display.

Hi Sandipt,

We’ve never used an MST hub before so we’ve never had this problem before, no. All current and previous drives that I’ve tried work fine if the monitor is not connected via an MST hub.

EVGA company, new product (has no part number yet AFAICT). Based on ST STDP4320 chipset

Attach display via MST hub, try to read EDID using I2C interface as documented here:
http://us.download.nvidia.com/XFree86/Linux-x86/319.32/README/i2c.html
Using code based on this:
https://www.kernel.org/doc/Documentation/i2c/dev-interface

I think we already tracking this issue internally in Bug 1417009.