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