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

[Sanford Rockowitz]

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?

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20170505/49e4d20d/attachment-0001.html>