<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_REOPENED "
   title="REOPENED - Resolution max problem since kernel 4.13"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=104292#c5">Comment # 5</a>
              on <a class="bz_bug_link 
          bz_status_REOPENED "
   title="REOPENED - Resolution max problem since kernel 4.13"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=104292">bug 104292</a>
              from <span class="vcard"><a class="email" href="mailto:ville.syrjala@linux.intel.com" title="Ville Syrjala <ville.syrjala@linux.intel.com>"> <span class="fn">Ville Syrjala</span></a>
</span></b>
        <pre>There are link training failures. The old code just ploughed on without caring
about them, but the current code will try to reduce the link rate/lane count
and retry the modeset. This will reduce the overall bandwidth available and we
start to drop modes from the list. It appears you have one of those magical
devices that happen to work despite them telling us that the link couldn't be
trained.
Figuring out why the link training fails would be the best approach here.

That said, the way we pick the link params vs. the way we reduce them results
in a rather strange sequence of events. We start by using the 1080p mode, then
we fall back to 1080i, then we go back to 1080p again, then 1080i, and finally
we drop the the 1152x720. And in the end even the final attempt at link
training at 1.62 ghz with 1 lane fails. Makes for confusing logs if nothing
else.</pre>
        </div>
      </p>


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

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