Regression: DDC I2C Display Freezing for internal displays

[Mario Limonciello]

On 7/19/25 12:02 PM, Felix Richter wrote:
> On 7/19/25 14:23, Mario Limonciello wrote:
>>
>> On 7/19/25 5:10 AM, Felix Richter wrote:
>>> Thanks for the reply.
>>>
>>> I am aware that i can read and `edid` via sysfs from the drm device. 
>>> I did not know about `drm_info` but from a quick look at it I don't 
>>> think it provides the information I need.
>>>
>>> The problem is not that I need more information about the attached 
>>> display. The problem is that there is not enough information about 
>>> the what `i2c` device corresponds to which monitors ddc channel. 
>>> Relying on udev hierarchies is not sufficient, because in many cases 
>>> the relevant i2c device has no parent drm output device. So when I 
>>> have no information about the i2c device I need to get more 
>>> information by reading from it. Then I know more and can map the 
>>> device to the correct display. I am happy to change the approach if 
>>> there is a simpler way for me to get this information.
>>
>> ❯ ls -alh /sys/class/drm/*/ddc
> Nice, I will consider adding that information to the logic for matching 
> i2c devices to displays. But I do have to tell you that still is not 
> sufficient in every case. It probably works for all direct interfaces 
> that are always present on the device. But it fails to match i2c ddc 
> channels when monitors are attached via a docking station using USB-C. 
> Those monitors will not even show up in the command you provided. This 
> again leads me to having to probe the i2c device directly anyway.

Presumably you're meaning with a dock that has an MST hub?

I suppose an optimization that you can do to avoid hitting this issue 
you've raised is exclude the matches to eDP panels from /sys/class/drm/.

> 
>> I get where you're coming from, but there are cases that are 
>> ultimately impossible to prevent when it comes to "long", or 
>> "frequent" sequences and responding to interrupts. There are lots of 
>> examples like this in the kernel that if you break what a driver is 
>> doing with a device from a userspace interface you get to pick up the 
>> pieces.
>>
>> I'll give you two examples:
>>
>> 1) You can access R/W PCI config data.
>> /sys/bus/pci/devices/*/config
>>
>> You can break power management state machines, bus mastering, really 
>> anything a device driver can do from a userspace application.  For 
>> example if I had a userspace app that did something like this:
>>
>> dd if=/dev/zero of=/sys/bus/pci/devices/${BDF}/config bs=1 count=4096
>>
>> and it broke how can the kernel do anything about it?
>>
>> 2) There was a case that fwupd was doing something very similar to you 
>> with a "probe" but with the DP aux character device.  It was trying to 
>> detect devices with updates and would fight specifically with link 
>> training.  The outcome was non-functional devices.  The workaround 
>> currently employed is that fwupd will wait a few seconds (5 or 10, I 
>> forget) and then do the probe to avoid that fight.  This doesn't solve 
>> things though because there are pulse interrupts that could still come 
>> at any time. The DP spec has response requirements for these.
>>
>> We talked about it at the display next hackfest this year and the 
>> decision was this information that fwupd was needing should be pushed 
>> into the kernel (let fwupd probe a sysfs file that gets cached data 
>> the driver fetched).
>>
> I get that you can not protect against every case of malicious use. I am 
> not sure that my example qualifies as that extreme though. I am only 
> trying to read some data, that is in no way comparable to actively 
> changing values.

Reading a lot of data (such as an EDID) can take a "while".  If you're 
in the middle of the I2C transactions and the driver tries to put it 
into PSR I guess that's where things are going wrong.

Maybe what we need in this case is to actively block PSR while userspace 
I2C traffic is happening?

This is a better question for Leo if that's feasible (or reasonable).

>>
>>> People have been experiencing similar screen freezing issues randomly 
>>> on this drm issue thread: https://gitlab.freedesktop.org/drm/amd/-/ 
>>> issues/4141#note_3016182> > This example highlights an issue that can 
>>> be triggered reliably with a
>>> very similar effect. It may not be the same issue, but they may be 
>>> related.
>>
>> Yeah; I'm aware of this thread and agree it's an issue with similar 
>> symptoms.
> 
> At the very least I hope that my example code for triggering a similar 
> issue can help figure out what is going on there ;)