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

[Ville Syrjälä]

On Fri, May 05, 2017 at 03:53:39AM -0400, Sanford Rockowitz 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.

Apart from the MST issues already mentioned, I have noticed (at least
with some displays) that the DDC/CI slaves don't seem to do clock
stretching properly, and that the default 100kHz clock tends to be
too much for them. A while ago I tried to cook up some hacks to work
around these issues both in our i2c and i2c-over-aux code. The idea
was to just reduce the bus speed whenever DDC/CI is being attempted.

My hacks are here:
git://github.com/vsyrjala/linux.git i2c_bus_speed

But do note that I've not seem many DP dongles that actually support
the i2c bus speed control, so the usefulness of the i2c-over-aux
part of that code might be a little questionable. I also didn't
implement anything for the MST case, so those would still be using
whatever is the default bus speed.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Jani Nikula]

On Fri, 05 May 2017, Sanford Rockowitz  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-de...@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  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  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), 

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

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

[Jani Nikula]

On Fri, 05 May 2017, Sanford Rockowitz  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  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, 

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


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Jani Nikula]

On Fri, 05 May 2017, Sanford Rockowitz  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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Sanford Rockowitz]

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.

Sanford Rockowitz

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx