<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [CI][SHARDS] igt@pm_rpm@i2c - fail - Test assertion failure function test_i2c - Failed assertion: diff <= vga_outputs && diff >= 0"
href="https://bugs.freedesktop.org/show_bug.cgi?id=104097#c15">Comment # 15</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [CI][SHARDS] igt@pm_rpm@i2c - fail - Test assertion failure function test_i2c - Failed assertion: diff <= vga_outputs && diff >= 0"
href="https://bugs.freedesktop.org/show_bug.cgi?id=104097">bug 104097</a>
from <span class="vcard"><a class="email" href="mailto:arkadiusz.hiler@intel.com" title="Arek Hiler <arkadiusz.hiler@intel.com>"> <span class="fn">Arek Hiler</span></a>
</span></b>
<pre>Indeed, on ICL we have seen only the (i2c edids = drm edids - 1) failure mode,
e.g.:
(i915_pm_rpm:12284) DEBUG: i2c edids:1 drm edids:2 vga outputs:0
On other machines we see:
i915_pm_rpm:1186) DEBUG: i2c edids:1 drm edids:0 vga outputs:0
<a href="https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_270/fi-hsw-4770r/igt@i915_pm_rpm@i2c.html">https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_270/fi-hsw-4770r/igt@i915_pm_rpm@i2c.html</a>
Current implementation is rather naive, and goes through /dev/i2c-* trying to
read out EDID:
while ((dirent = readdir(dir))) {
if (strncmp(dirent->d_name, "i2c-", 4) == 0) {
sprintf(full_name, "/dev/%s", dirent->d_name);
fd = open(full_name, O_RDWR);
igt_assert_neq(fd, -1);
if (i2c_edid_is_valid(fd))
ret++;
close(fd);
}
}
The drmModeRes part is as sophisticated:
while ((dirent = readdir(dir))) {
if (strncmp(dirent->d_name, "i2c-", 4) == 0) {
sprintf(full_name, "/dev/%s", dirent->d_name);
fd = open(full_name, O_RDWR);
igt_assert_neq(fd, -1);
if (i2c_edid_is_valid(fd))
ret++;
close(fd);
}
}
I think we should change implementation a bit and add extra logging around
this, i.e. use /sys/class/drm/card?-*/i2c-* to do readouts, and compare EDIDs
on a connector basis, printing out both in case one is corrupted. This may tell
us something about particular screen or connectors that are being troublesome.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>