[Intel-gfx] i915 I2C failures with recent chips and docking stations

[Jani Nikula]

On Fri, 05 May 2017, Sanford Rockowitz <rockowitz at minsoft.com> wrote:
> I am the author of ddcutil (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.  Communication works when the video cable is plugged
> directly into the laptop.   There also seems to be a correlation with
> whether a DisplayPort cable is being used (i.e. the I2C-over-aux path is
> being executed), though this correlation is not as clear.
>
> I'm not sure how best to go about reporting these issues.  The usual bug
> reporting mechanism asks for detailed information about a specific
> system, which I don't have.   What I do have is the ability to see a
> pattern.
>
> Because I2C communication is so fragile (dependencies on hardware
> quirks, drivers, etc), ddcutil (which is written in C) has an extensive
> subsystem devoted to remotely diagnosing user configurations.  It
> already reports DDC (i.e. I2C) communication errors, and has interfaces
> to udev, libdrm, and x11 libraries.  If there is some i915 specific code
> I could add to refine the diagnosis, I would be happy to add that. 
> (Note: ddcutil is entirely a user space program, using the i2c-dev
> interface.)
>
> Suggestions on how to proceed appreciated.

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.

Instead of using the I2C device directly for, say, card0-DP-1 or
DPDDC-A, you need to be using the dynamically created and removed DP MST
I2C devices that wrap the communications to remote I2C-over-AUX. Frankly
I am not sure if the naming or parent/child relationships of the devices
are quite right (based on looking at the code), but you should find the
sysfs name attribute will be DPMST. I'm also not sure how you can
associate those with the physical devices you have.

If you have an option to tell your tool which I2C device to use, that
should get you started and debugging. If there are issues with that,
please let us know.

In the long run, we should probably do something to make the discovery
of the DP MST I2C devices easier, with naming and/or better parent/child
relationships of the devices. It's just that the userspace I2C interface
was probably pretty far down on the list of priorities when writing DP
MST.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center