Same MST display appears as 2 /dev/i2c devices

Please forgive the cross-posting. I don't see a better way to report a problem that applies to both i915 and amdgpu. See amdgpu issue 1622, Same MST display appears as 2 /dev/i2c devices.

changed title from Same MST display appears as 2 different /dev/i2c devices to Same MST display appears as 2 /dev/i2c devices

changed the description

I'm one of the people reporting on the bug in ddcutil. My situation is a "DELL U2415" connected via. DisplayPort to a NUC5i3RYB w/HD Graphics 5500. I see 2 /dev/i2c-* devices for the same monitor, one named "AUX C/port C" the other "DPMST". Both devices can control the monitor via. ddcutil, I just need one of them to be hidden to solve my particular case.

I also have another identical "DELL U2415" daisy-chained on this monitor, which is available with it's own "DPMST" device. This is a red-herring as far as the bug report goes, whether it's connected or not isn't relevant to the core issue above, but it does mean I can't just disable MST and call it a day.

@rockowitz can you please try to reproduce this issue on latest drm-tip. https://cgit.freedesktop.org/drm-tip Please post your observations on it and any steps followed to reproduce the issue described at https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs

added Community label

@rveesam I do not myself have a configuration for testing. However, I will post your request on the ddcutil issue for this bug. Does the fix apply only to the i915 driver, or does it apply to drm drivers more generally, particularly amdgpu?

If you install ddcutil on your system, I should be able to analyse the output. Execute command "ddcutil environment --verbose". You can submit the output by attaching the file here, attaching it to the ddcutil issue for this bug, or simply emailing it to rockowitz@minsoft.com. Thank you.

added feature: display/DP MST label

Basically the "main" i2c device is registered for the physical connector at the driver probe time. (Called "AUX C/Port C" in the above case.) That's what you need to use if an SST (single-stream) display gets plugged in, there's nothing else.

The DPMST i2c devices may come and go as the DP MST (multi-stream) topology and end-points change, e.g. when SST displays are plugged into or out of DP MST docks.

I don't think we can remove the former in any case (we'll need it for hotplug in kernel), and in the case of a display connected via DP MST, you should be using the latter.

I think the only question is how the main i2c device should function if there are DP MST endpoints connected. I'm not sure if there's something that could be done about that.

For my purposes, it's not a matter of dynamically adding/removing the main /dev/i2c device. The problem is that when one or more MST monitors are plugged in, slave addresses x50 and sometimes x37 from one of the MST monitors are duplicated on the on the main /dev/i2c device.

It's not so much that they are "duplicated"; it's more of a question where the i2c traffic on the main connector i2c device ends up if MST devices are connected. It may actually depend on the MST branch device (e.g. dock) what it does with the i2c access.

@vsyrjala Thoughts?

@lyudess You've done a bunch of work on DP MST, any ideas?

I can't find anything in the spec to describe what the SST i2c-over-aux is supposed to do if DP MST is active. Somehow the messages end up to the DP MST endpoint. Is that a feature or a bug, and if the latter, our bug or the branch device's?

I don't think we even could do anything at the DP SST drm_dp_i2c_xfer level. There's no access to any info about DP MST. The DP MST drm_dp_mst_i2c_xfer() has to work, can't do anything there. In i915 level, the intel_dp_aux_transfer() can't trivially figure out where the message is originating from and where it's going.

I don't recall if we have a nice presentation of the MST topology eg. in debugfs. If not we should probably add one. IIRC the registration of the i2c bus had something to do with the peer device type of the port, but I don't recall the details right now.

As for finding the correct i2c node for a particular display I think we should just start populating the connector->ddc pointer which should create the correct symlink in sysfs IIRC.

commit 959fb1a68652 ("drm/i915/mst: Populate connector->ddc")
commit 84fd19644aef ("drm/i915/dp: Populate connector->ddc")
commit 4aad8b9d0e7f ("drm/i915/dvo: Populate connector->ddc")
commit 96f0ef50bfc6 ("drm/i915/crt: Populate connector->ddc")
commit 08a629fff8c9 ("drm/i915/lvds: Populate connector->ddc")

are now in. So the "ddc" symlink should be present pretty much always.

Had to revert the MST part due to ordering issue in the core MST code :( Neeeds more work.

@rockowitz Do you have any further query on this issue as Jani has explained in the detailed.

I appreciate the discussion of the complexity of the problem, and as someone who programs on the userland side, have nothing to add as to how the problem might be addressed.

What would be helpful is if the use of sysfs was documented with the aim of standardizing it across video drivers. For example, some drivers populate a /sys/class/drm/cardN-connector/drm_dp_auxN subdirectory, others do not. Some drivers define a /sys/clas/drm/cardN-connector/ddc directory, others (at least nvidia) do not. There are many "name" attributes - which are guaranteed to be identical?

ddc is supposed to be a symlink to the i2c adapter for the connector, and that's supposed to be the "standard". But not all drivers populate the DDC pointer to have that happen automatically.

drm_dp_auxN provides access to the Display Port DPCD if CONFIG_DRM_DP_AUX_CHARDEV=y.

Upstream does not care what nvidia does, because it's a closed source driver.

@rockowitz Is your query answered?

mentioned in commit nouveau@959fb1a6