[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:
> 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.

If I understand you right, the former. The connections look like
independent DP sinks. (Even for DVI/HDMI; the conversion is in the dock
in DP MST based docks.)

> 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.

Seems like this should work.

> 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.

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.

> 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?

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

BR,
Jani.

>
>
> 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.
>>
>>
>
>

-- 
Jani Nikula, Intel Open Source Technology Center