i915 i2c-dev failures with recent chips and docking stations

Submitted by Sanford Rockowitz

Assigned to Intel GFX Bugs mailing list

Link to original bug (#100954)

Description

I am the author of ddcutil (http://www.ddcutil.com), a Linux utility that
manages monitor settings using DDC/CI. I am seeing a pattern of user
error reports in which I2C communication is not working when a system
with a recent Intel chip, using the i915 driver, is plugged into a
docking station.

ddcutil looks for displays by examining all non-SMBus /dev/i2c devices
on the system. If checks for the presence of slave address x50 and
x37. If they exist it tries to read the EDID on x50 and a Virtual
Control Panel feature value on x37. Looking at one of the user logs, I
see that a couple /dev/i2c-n devices have udev sysattr name DPMST. When
ddcutil probes those /dev/i2c devices, slave addresses x50 and x37
appear active, but reading the EDID fails.

The issue was discussed in this thread (https://lists.freedesktop.org/archives/intel-gfx/2017-May/127350.html) on the intel-gfx mailing list.

Comments from Jani Nikula:

The issues are related to DP MST (Multi-Stream Transport) that the docks
use nowadays. The single DP link is divided to several logical links to
sink devices. The I2C communication needs to be encapsulated to remote
I2C-over-AUX reads and writes, with the logical DP MST addresses, to
route them to the correct sinks. In kernel, this is handled by the MST
topology manager.

...

I think it's more likely the issue is in core drm DP MST code, and
nobody ever tried the I2C interface for them. The core I2C code should
be completely ignorant about DP MST, or even DP for that matter.

...

You'll want the DP MST I2C code fixed. Well, at least it's my guess
that's where the problem is.