<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - [GLK] [IGT] testdisplay -a shows corruption on HDMI 4k display" href="https://bugs.freedesktop.org/show_bug.cgi?id=100440#c22">Comment # 22</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - [GLK] [IGT] testdisplay -a shows corruption on HDMI 4k display" href="https://bugs.freedesktop.org/show_bug.cgi?id=100440">bug 100440</a> from <a class="email" href="mailto:shashank.sharma@intel.com" title="shashank.sharma@intel.com <shashank.sharma@intel.com>"> shashank.sharma@intel.com</a> <pre>(In reply to Ander Conselvan de Oliveira from <a href="show_bug.cgi?id=100440#c19">comment #19</a>) > (In reply to Luis Botello from <a href="show_bug.cgi?id=100440#c18">comment #18</a>) > > After testing testdisplay on HDMI I am getting "No Signal" on HDMI screen > > while test sets CRTC(36):[7] 2560x1440 60 2560 2608 2640 2720 1440 1443 > > 1448 1481 0x9 0x40. > > This seems related to HDMI 2.0 high TMDS clock ratio. If I force the driver > to not enable the tmds clock ratio, that mode works. Does this work only by blocking high TMDS clock, or both scrambling and TMDS clock ? > > I tested custom modes based on the failing one but changing the clock. If > the port clock was below 340, then the driver doesn't enable scrambling and > the monitor is able to display image. With port clock between [340,405) I > got no signal. With port clock >= 405, there was image on the screen. > Looks like we are seeing the problem when the actual mode's clock < 340, but its getting > 340 only due to 12 BPC multiplier. The Bspec clearly says that whenever driving clock > 340, set the TMDS clock ratio, and scrambling from source. But Looks like we need to experiment and check if this applies to the native clock of the mode, or does it apply to 12bpc clock too ? > Curiously, if I forced 8 bpc and let scrambling and high tmds clock ratio be > enabled normally, the following mode worked: > > ./testdisplay -f "362.25,2560,2608,2640,4080,1440,1443,1448,1481" -o 68 > > I also tested enabling the given mode with only scrambling and only high > tmds. > > scrambling high tmds result > yes yes fail > yes no pass > no yes fail > no no pass > This is very informative. So looks like TMDS clock ratio is a major player here. The Bspec says always enable TMDS clock high ratio when driving clocks > 340M, but we should check on if this clock is 12BPC clock, or native mode's clock. > So this seems to be a combination of 12 bpc, a port clock in the range > [340,405) and high tmds ratios. But as far as I can tell, we are following > the spec with respect to those. Shashank, any ideas? To me, these should be the points to probe: - While enabling scrambling, should we consider native port clock Or 12 BPC clock ? - While enabling TMDS clock high ratio, should we consider native port clock, or 12 BPC clock ? - While driving 12BPC, is there something missing in AVI IF packets (I will check into HDMI specs too) I will reproduce this issue today, and update more here. - Shashank</pre> </div> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - [GLK] [IGT] testdisplay -a shows corruption on HDMI 4k display" href="https://bugs.freedesktop.org/show_bug.cgi?id=100440#c21">Comment # 21</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - [GLK] [IGT] testdisplay -a shows corruption on HDMI 4k display" href="https://bugs.freedesktop.org/show_bug.cgi?id=100440">bug 100440</a> from <a class="email" href="mailto:shashank.sharma@intel.com" title="shashank.sharma@intel.com <shashank.sharma@intel.com>"> shashank.sharma@intel.com</a> <pre>(In reply to Ander Conselvan de Oliveira from <a href="show_bug.cgi?id=100440#c19">comment #19</a>) > (In reply to Luis Botello from <a href="show_bug.cgi?id=100440#c18">comment #18</a>) > > After testing testdisplay on HDMI I am getting "No Signal" on HDMI screen > > while test sets CRTC(36):[7] 2560x1440 60 2560 2608 2640 2720 1440 1443 > > 1448 1481 0x9 0x40. > > This seems related to HDMI 2.0 high TMDS clock ratio. If I force the driver > to not enable the tmds clock ratio, that mode works. Does this work only by blocking high TMDS clock, or both scrambling and TMDS clock ? > > I tested custom modes based on the failing one but changing the clock. If > the port clock was below 340, then the driver doesn't enable scrambling and > the monitor is able to display image. With port clock between [340,405) I > got no signal. With port clock >= 405, there was image on the screen. > Looks like we are seeing the problem when the actual mode's clock < 340, but its getting > 340 only due to 12 BPC multiplier. The Bspec clearly says that whenever driving clock > 340, set the TMDS clock ratio, and scrambling from source. But Looks like we need to experiment and check if this applies to the native clock of the mode, or does it apply to 12bpc clock too ? > Curiously, if I forced 8 bpc and let scrambling and high tmds clock ratio be > enabled normally, the following mode worked: > > ./testdisplay -f "362.25,2560,2608,2640,4080,1440,1443,1448,1481" -o 68 > > I also tested enabling the given mode with only scrambling and only high > tmds. > > scrambling high tmds result > yes yes fail > yes no pass > no yes fail > no no pass > This is very informative. So looks like TMDS clock ratio is a major player here. The Bspec says always enable TMDS clock high ratio when driving clocks > 340M, but we should check on if this clock is 12BPC clock, or native mode's clock. > So this seems to be a combination of 12 bpc, a port clock in the range > [340,405) and high tmds ratios. But as far as I can tell, we are following > the spec with respect to those. Shashank, any ideas? To me, these should be the points to probe: - While enabling scrambling, should we consider native port clock Or 12 BPC clock ? - While enabling TMDS clock high ratio, should we consider native port clock, or 12 BPC clock ? - While driving 12BPC, is there something missing in AVI IF packets (I will check into HDMI specs too) I will reproduce this issue today, and update more here. - Shashank</pre> </div> <hr> You are receiving this mail because: <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>