<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_ASSIGNED "
   title="ASSIGNED - [IGT][CI] kms_sysfs_edid_timing test Failed assertion: mean.mean < (THRESHOLD_TOTAL * 1e6)"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=100047#c54">Comment # 54</a>
              on <a class="bz_bug_link 
          bz_status_ASSIGNED "
   title="ASSIGNED - [IGT][CI] kms_sysfs_edid_timing test Failed assertion: mean.mean < (THRESHOLD_TOTAL * 1e6)"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=100047">bug 100047</a>
              from <span class="vcard"><a class="email" href="mailto:petri.latvala@intel.com" title="Petri Latvala <petri.latvala@intel.com>"> <span class="fn">Petri Latvala</span></a>
</span></b>
        <pre>The test is checking that an EDID read can be completed under a selected time
limit. The problem is that whatever the selected time limit is, it's going to
be incorrect for some configurations.

The time for reading the EDID can be different based on the presence of
external encoders (LSPCON), topology of the cabling, .........

We could apply heuristics for setting proper time limits by checking the
configuration and so on, but that's basically rewriting the kernel code in IGT
and we really want to test for the behaviour instead.

The end goal of this kind of testing is to test that the time to read the EDID
does not _regress_ on this-and-that configuration, and the comparison to be
done is the time the read took on another occasion on the exact same hardware
and configuration. In other words, a performance test.

The above is the discussion outcome Marta referenced in <a href="show_bug.cgi?id=100047#c51">comment #51</a>.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the QA Contact for the bug.</li>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>