<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Display Port BYT-M [N2807] - Data link training fails sporadically" href="https://bugs.freedesktop.org/show_bug.cgi?id=93956#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Display Port BYT-M [N2807] - Data link training fails sporadically" href="https://bugs.freedesktop.org/show_bug.cgi?id=93956">bug 93956</a> from <a class="email" href="mailto:zoran.stojsavljevic@intel.com" title="Zoran Stojsavljevic <zoran.stojsavljevic@intel.com>"> Zoran Stojsavljevic</a> <pre>Hello OTC team, Today, as I have promised, Werner Zeh from Siemens MC came to IMU Feldkirchen, to work with me together on the DDI Port C BYT-M (N2807) issue/bug. The following we did, in order to close to the potential FW problem and to find the Root Cause of this problem. [1] I did use my BBAY Fab. 3 CRB, swapping E3826 (two core BYT-I) with issue infested N2807 BYT-M. The reballed "bad" N2807 worked immediately with BBAY Fab. 3. [2] Once I had problematic N2807, I did verify all the parameters from CCG internal BIOS X64.A093.R42 I have build, to check the validity of this BIOS. [3] The BIOS shows correct 0x30678 N2807 BYT-M CPUID, as well as the latest used MCU 833. [4] The BIOS implemented (assembled by me) appears to be UEFI compliant BIOS, 64 bit one, visually checked with version, as well as with .efi 32/64 size checker. [5] With this BIOS (X64.A093.R42) it is IMPOSSIBLE to experience/show this issue with EMGD vBIOS 3909, as well as with GOP 7.2.1013 (used Fedora 23, kernel 4.3.5-300.fc23.x86_64)! [6] Then we switch gears to FSP MR4/MR5 (irrelevant, both work the same way), and single channel N2807 does expose/show this issue very clearly. [7] There was investigation going on, so we concluded that something in FSP is not either initialized accordingly with UEFI BIOS, or there is time de-synchronization. [8] I set this use case according to INTEL rules to prove this issue on BBAY Fab.3 CRB, with FSP used. [9] I have BBAY Fab.3 CRB with N2807 and FSP as real prove that we, INTEL, have the problem! Now... I am just wondering if anything can/could be done from OTC/booting kernel levels, so some additional registers can be initialized by i915 driver to solve this issue (it is clear that issue comes from legacy BIOS/FSP levels, which does not necessarily mean that it could not be fixed by Linux kernel using i915 GFX driver). Thank you for understanding, Zoran</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>