* i915 I2C failures with recent chips and docking stations @ 2017-05-05 7:53 Sanford Rockowitz 2017-05-05 9:59 ` Jani Nikula 2017-05-05 20:27 ` Ville Syrjälä 0 siblings, 2 replies; 7+ messages in thread From: Sanford Rockowitz @ 2017-05-05 7:53 UTC (permalink / raw) To: Intel-gfx 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: i915 I2C failures with recent chips and docking stations 2017-05-05 7:53 i915 I2C failures with recent chips and docking stations Sanford Rockowitz @ 2017-05-05 9:59 ` Jani Nikula 2017-05-05 14:05 ` Sanford Rockowitz 2017-05-05 20:27 ` Ville Syrjälä 1 sibling, 1 reply; 7+ messages in thread From: Jani Nikula @ 2017-05-05 9:59 UTC (permalink / raw) To: Sanford Rockowitz, Intel-gfx On Fri, 05 May 2017, Sanford Rockowitz <rockowitz@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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: i915 I2C failures with recent chips and docking stations 2017-05-05 9:59 ` Jani Nikula @ 2017-05-05 14:05 ` Sanford Rockowitz 2017-05-05 16:49 ` Jani Nikula 0 siblings, 1 reply; 7+ messages in thread From: Sanford Rockowitz @ 2017-05-05 14:05 UTC (permalink / raw) To: Jani Nikula, Intel-gfx 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@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. > > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: i915 I2C failures with recent chips and docking stations 2017-05-05 14:05 ` Sanford Rockowitz @ 2017-05-05 16:49 ` Jani Nikula 2017-05-05 19:47 ` Sanford Rockowitz 0 siblings, 1 reply; 7+ messages in thread From: Jani Nikula @ 2017-05-05 16:49 UTC (permalink / raw) To: Sanford Rockowitz, Intel-gfx On Fri, 05 May 2017, Sanford Rockowitz <rockowitz@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@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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: i915 I2C failures with recent chips and docking stations 2017-05-05 16:49 ` Jani Nikula @ 2017-05-05 19:47 ` Sanford Rockowitz 2017-05-05 20:09 ` Jani Nikula 0 siblings, 1 reply; 7+ messages in thread From: Sanford Rockowitz @ 2017-05-05 19:47 UTC (permalink / raw) To: Jani Nikula, Intel-gfx [-- Attachment #1.1: Type: text/plain, Size: 5320 bytes --] 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@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@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. >>> >>> >> [-- Attachment #1.2: Type: text/html, Size: 6639 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: i915 I2C failures with recent chips and docking stations 2017-05-05 19:47 ` Sanford Rockowitz @ 2017-05-05 20:09 ` Jani Nikula 0 siblings, 0 replies; 7+ messages in thread From: Jani Nikula @ 2017-05-05 20:09 UTC (permalink / raw) To: Sanford Rockowitz, Intel-gfx On Fri, 05 May 2017, Sanford Rockowitz <rockowitz@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@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@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@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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: i915 I2C failures with recent chips and docking stations 2017-05-05 7:53 i915 I2C failures with recent chips and docking stations Sanford Rockowitz 2017-05-05 9:59 ` Jani Nikula @ 2017-05-05 20:27 ` Ville Syrjälä 1 sibling, 0 replies; 7+ messages in thread From: Ville Syrjälä @ 2017-05-05 20:27 UTC (permalink / raw) To: Sanford Rockowitz; +Cc: Intel-gfx 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-05-05 20:27 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-05-05 7:53 i915 I2C failures with recent chips and docking stations Sanford Rockowitz 2017-05-05 9:59 ` Jani Nikula 2017-05-05 14:05 ` Sanford Rockowitz 2017-05-05 16:49 ` Jani Nikula 2017-05-05 19:47 ` Sanford Rockowitz 2017-05-05 20:09 ` Jani Nikula 2017-05-05 20:27 ` Ville Syrjälä
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox