[Bug 100440] [GLK] [IGT] testdisplay -a shows corruption on HDMI 4k display

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Apr 27 06:39:11 UTC 2017


https://bugs.freedesktop.org/show_bug.cgi?id=100440

--- Comment #21 from shashank.sharma at intel.com <shashank.sharma at intel.com> ---
(In reply to Ander Conselvan de Oliveira from comment #19)
> (In reply to Luis Botello from comment #18)
> > 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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20170427/e84056f9/attachment.html>


More information about the intel-gfx-bugs mailing list