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

[Sanford Rockowitz]

Jani,

Thanks for your quick and detailed response. 

You wrote:

> The single DP link is divided to several logical links to sink devices.

Suppose the dock has a DVI and/or HDMI connector.  Are those connectors
logical sinks to a master DisplayPort connection, or do they have their
own connection through the dock to the laptop?  If the former, then
telling people to use a DVI or HDMI connection on the dock would not be
a workaround. 

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. So it would seem that the
i2c-dev driver is not properly handling DP-MST.   Does that
interpretation seem correct?  If so, I'll bounce the issue over to the
I2C folks.

Alternatively, do the DP-MST devices present as some other userspace
device that I can program to?  I imagine that searching udev for sysattr
name DPMST would find any place in the /dev tree besides /dev/i2c where
the devices are surfaced.   Would this be a bit-banging interface, or
something at a higher level?  Or would I need to write a device driver?

Thanks again,
Sanford



On 05/05/2017 05:59 AM, Jani Nikula wrote:
> 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.
>
>