[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:
> Last question (I think).   You wrote:
>
>> You'll want the DP MST I2C code fixed. Well, at least it's my *guess*
> that's where the problem is.
>
> Where do I go to post this problem?

Sorry, I could have added that in my previous reply!

https://bugs.freedesktop.org/enter_bug.cgi?product=DRI and/or
dri-devel at lists.freedesktop.org. Please Cc me in either.

BR,
Jani.


>
> Thanks,
> Sanford
>
>
> On 05/05/2017 12:49 PM, Jani Nikula wrote:
>> 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