Created attachment 130519 [details]
Corruption_Picture

Updated to highest/blocker due to impact on Alpha results.

Assign to Ander for preliminary investigation.

unable to reproduce this on my GLK A1. It's interesting that the colors do not fade on the right side of the screen like they should from testdisplay.

Created attachment 130679 [details]
GLK HDMI 1080p24

Attached output from GLK RVP HDMI output. No corruption seen.

Could the OP post their kernel command line parameters or a full dmesg log.

Luis, can you please attach a dmesg from boot? You might need to add log_buf_len=4M to the kernel command line.

Also, what is the model number of the monitor being used.

Hi Luis,
Please check the info needed by Ander.
Thanks

This issue is still happening on my GLK, my HDMI display is an acer S277HK ED 27" 3840X2160 .

While test is running some resolutions are not displayed and got the message: "Input Not Supported" in the screen and after this all the other resolutions tested have corruption.

CRTC(36):[0]  3840x2160 60 3840 3888 3920 4000 2160 2163 2168 2222 0x9 0x48 533250 - ok
CRTC(36):[1]  3840x2160 30 3840 4016 4104 4400 2160 2168 2178 2250 0x5 0x40 297000 - ok
CRTC(36):[2]  3840x2160 30 3840 4016 4104 4400 2160 2168 2178 2250 0x5 0x40 296703 - ok
CRTC(36):[3]  3840x2160 25 3840 4896 4984 5280 2160 2168 2178 2250 0x5 0x40 297000 - ok
CRTC(36):[4]  3840x2160 24 3840 5116 5204 5500 2160 2168 2178 2250 0x5 0x40 297000 - Input Not Supported
CRTC(36):[5]  3840x2160 24 3840 5116 5204 5500 2160 2168 2178 2250 0x5 0x40 296703 - Input Not Supported
CRTC(36):[6]  3840x2160 24 3840 3888 3920 4000 2160 2163 2168 2185 0x5 0x40 209800 - Input Not Supported
CRTC(36):[7]  2560x1440 60 2560 2608 2640 2720 1440 1443 1448 1481 0x9 0x40 241500 - corruption
CRTC(36):[8]  1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 0x5 0x40 148500 - corruption
CRTC(36):[9]  1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 0x5 0x40 148352 - corruption
.
.
.
CRTC(36):[44]  720x400 70 720 738 846 900 400 412 414 449 0x6 0x40 28320 - corruption


Config:
======================================
kernel version              : 4.11.0-rc7-drm-tip-ww16-commit-1b75708+
architecture                : x86_64
os version                  : Ubuntu 16.10
bios revision               : 43.30
bios release date           : 04/11/2017
ksc                         : 1.25
libdrm                      : 2.4.80
cairo                       : 1.15.5
intel-gpu-tools (tag)       : intel-gpu-tools-1.18-86-gac1fe09
intel-gpu-tools (commit)    : ac1fe09


kernel parameters
======================================
quiet splash drm.debug=0xe i915.enable_guc_loading=2 i915.enable_guc_submission=2 i915.alpha_support=1 log_buf_len=4M


Attachments
======================================
igtOutput
demsgAfterTestdisplay
demsgAtBootHDMIandEDP

Created attachment 130948 [details]
igtOutput

Created attachment 130949 [details]
demsgAfterTestdisplay

Created attachment 130950 [details]
demsgAtBootHDMIandEDP

As additional info, I was not able to reproduce the issue on a non-4K HDMI display.

I was able to reproduce it with that monitor. I narrowed the steps down to:

 1. testdisplay -i 68,4  # sets 3840x2160@24 mode; monitor says no signal
 2. testdisplay -i 68,8  # sets 1920x1080@60 mode; shows corruption

The mode that produces no signal is the following, but the failure only happens when using 12 bpc. If I force 8 bpc the monitor outputs the correct image and no corruption follows.

[4]  3840x2160 24 3840 5116 5204 5500 2160 2168 2178 2250 0x5 0x40 297000

After this, the pipe seems to be stuck with wrong settings. The following warning happens on every attempt to disable the pipe. After a suspend/resume cycle the warning and the corruption goes away though.

[  574.274272] WARNING: CPU: 2 PID: 1400 at drivers/gpu/drm/i915/intel_display.c:1025 intel_disable_pipe+0x16d/0x2c0 [i915]
[  574.274274] pipe_off wait timed out
[  574.274277] Modules linked in: tun ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ip6table_mangle ip6table_security ip6table_raw ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_l
[  574.274441]  serio_raw
[  574.274451] CPU: 2 PID: 1400 Comm: testdisplay Tainted: G        W       4.11.0-rc7ander+ #367
[  574.274453] Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0035.B33.1702150552 02/15/2017
[  574.274456] Call Trace:
[  574.274471]  dump_stack+0x86/0xc3
[  574.274481]  __warn+0xcb/0xf0
[  574.274493]  warn_slowpath_fmt+0x5a/0x80
[  574.274572]  intel_disable_pipe+0x16d/0x2c0 [i915]
[  574.274642]  haswell_crtc_disable+0x81/0x170 [i915]
[  574.274714]  intel_atomic_commit_tail+0x13d/0x1040 [i915]
[  574.274722]  ? finish_task_switch+0xa5/0x260
[  574.274726]  ? finish_task_switch+0x69/0x260
[  574.274738]  ? __schedule+0x316/0xa50
[  574.274815]  intel_atomic_commit+0x3ef/0x4f0 [i915]
[  574.274868]  drm_atomic_commit+0x4b/0x50 [drm]
[  574.274889]  restore_fbdev_mode+0x14d/0x290 [drm_kms_helper]
[  574.274911]  drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x80 [drm_kms_helper]
[  574.274929]  drm_fb_helper_set_par+0x2d/0x60 [drm_kms_helper]
[  574.274992]  intel_fbdev_set_par+0x1a/0x70 [i915]
[  574.275002]  fb_set_var+0x23c/0x480
[  574.275055]  fbcon_blank+0x312/0x360
[  574.275064]  ? mark_held_locks+0x6f/0xa0
[  574.275100]  do_unblank_screen+0xd2/0x1a0
[  574.275107]  vt_ioctl+0x53e/0x13e0
[  574.275127]  tty_ioctl+0x3ae/0xee0
[  574.275135]  ? debug_lockdep_rcu_enabled+0x1d/0x20
[  574.275142]  ? __fd_install+0x5/0x2c0
[  574.275164]  do_vfs_ioctl+0xa3/0x6d0
[  574.275169]  ? kmem_cache_free+0x27c/0x2f0
[  574.275189]  SyS_ioctl+0x79/0x90
[  574.275203]  entry_SYSCALL_64_fastpath+0x1f/0xc2
[  574.275207] RIP: 0033:0x7f553caa8787
[  574.275210] RSP: 002b:00007ffefe6690e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[  574.275215] RAX: ffffffffffffffda RBX: 000000000235f400 RCX: 00007f553caa8787
[  574.275218] RDX: 0000000000000000 RSI: 0000000000004b3a RDI: 0000000000000008
[  574.275221] RBP: 000000000239db20 R08: 00007ffefe6690b0 R09: 0000000000000000
[  574.275223] R10: 0000000000000008 R11: 0000000000000246 R12: 0000000000000003
[  574.275225] R13: 00000000ffffffff R14: 00007f553cfe9000 R15: 0000000000000003

https://patchwork.freedesktop.org/series/23451/

Hi Luis,
Please check with the patch applied.
Thanks

Issue is not seen anymore with that patch series. But display is showing no image while running ./testdisplay -a and it goes into the following resolution:

CRTC(36):[7]  2560x1440 60 2560 2608 2640 2720 1440 1443 1448 1481 0x9 0x40 241500

Is there some way to force it or to set a higher timeout between each resolution?

(In reply to Luis Botello from comment #16)
> Issue is not seen anymore with that patch series. But display is showing no
> image while running ./testdisplay -a and it goes into the following
> resolution:
> 
> CRTC(36):[7]  2560x1440 60 2560 2608 2640 2720 1440 1443 1448 1481 0x9 0x40
> 241500
> 
> Is there some way to force it or to set a higher timeout between each
> resolution?

$ ./testdisplay -h
usage: ./testdisplay [-hiasdpmtf]
...
	-s	<duration>	sleep between each mode test

(In reply to Ander Conselvan de Oliveira from comment #17)
> (In reply to Luis Botello from comment #16)
> > Issue is not seen anymore with that patch series. But display is showing no
> > image while running ./testdisplay -a and it goes into the following
> > resolution:
> > 
> > CRTC(36):[7]  2560x1440 60 2560 2608 2640 2720 1440 1443 1448 1481 0x9 0x40
> > 241500
> > 
> > Is there some way to force it or to set a higher timeout between each
> > resolution?
> 
> $ ./testdisplay -h
> usage: ./testdisplay [-hiasdpmtf]
> ...
> 	-s	<duration>	sleep between each mode test

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.

Also as additional info I am getting extra low performance while 3840x2160 resolution is set on HDMI, and no signal if 2560x1440 resolution is set in UI.

(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.

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.

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

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?

(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.
> 
> Also as additional info I am getting extra low performance while 3840x2160
> resolution is set on HDMI, and no signal if 2560x1440 resolution is set in
> UI.

These are different issues, so I went ahead and pushed the patch for the corruption one.

commit 46649d8b6cb876e4f823e741d39959cf6e231e85
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date:   Mon Apr 24 13:47:18 2017 +0300

    drm/i915/glk: Don't allow 12 bpc when htotal is too big

(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

(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

Created attachment 131099 [details]
Modeset 25x14 using Mint-GUI

This is the output with same monitor (Acer 277*K) of modeset 25x14 using GUI

Created attachment 131100 [details]
Modeset 25x14 using testdisplay

This is the output of 25x14 modeset using testdisplay

Created attachment 131101 [details]
Intel userspace driver (used with X server)

This is the library I am using.

I was able to get a proper modeset on the said mode (25x16) on same monitor, using both Mint GUI as well as testdisplay.
There are 3 files attached with this message:
- Modeset 25x14 using Mint-GUI: Modeset 25x14 with GUI
- Modeset 25x14 using testdisplay: Modeset 25x14 with testdisplay

The command used in testdisplay was:
./testdisplay -f 241.5,2560,2608,2640,2720,1440,1443,1448,1481 

I also confirmed that:
- It was 12 BPC modeset
- The scrambling and high tmds clock was enabled during this modeset.
[ 1145.592443] [drm:intel_hdmi_compute_config] Shashank: picking bpc to 12 for HDMI output
[ 1145.593176] [drm:intel_hdmi_handle_sink_scrambling] Shashank: Setting sink scrambling=0 tmds=0 for enc:DDI C connector:HDMI-A-2
[ 1145.924969] [drm:intel_ddi_enable_transcoder_func] *ERROR* Shashank: Set source scrambling
[ 1145.934277] [drm:intel_hdmi_handle_sink_scrambling] Shashank: Setting sink scrambling=1 tmds=1 for enc:DDI C connector:HDMI-A-2

The only difference is, I was using an old intel_drv.so library. This lib comes with X package I guess, as its location is (/usr/lib/xorg/modules/drivers/intel_drv.so)

With the latest version of this libraray, I was not even getting the desktop on Mint-GUI, there was a crash during X modeset. I attached X with GDB, and saw the crash in this library. Then I used older version of this library, and with this I am not getting any crash. 

Library is also attached for further reference.

- Shashank

s/25x16/25x14/ in above comment.
The exact mode was 2560x1440@59.

(In reply to shashank.sharma@intel.com from comment #26)
> I was able to get a proper modeset on the said mode (25x16) on same monitor,
> using both Mint GUI as well as testdisplay.
> There are 3 files attached with this message:
> - Modeset 25x14 using Mint-GUI: Modeset 25x14 with GUI
> - Modeset 25x14 using testdisplay: Modeset 25x14 with testdisplay
> 
> The command used in testdisplay was:
> ./testdisplay -f 241.5,2560,2608,2640,2720,1440,1443,1448,1481 
> 
> I also confirmed that:
> - It was 12 BPC modeset
> - The scrambling and high tmds clock was enabled during this modeset.
> [ 1145.592443] [drm:intel_hdmi_compute_config] Shashank: picking bpc to 12
> for HDMI output
> [ 1145.593176] [drm:intel_hdmi_handle_sink_scrambling] Shashank: Setting
> sink scrambling=0 tmds=0 for enc:DDI C connector:HDMI-A-2
> [ 1145.924969] [drm:intel_ddi_enable_transcoder_func] *ERROR* Shashank: Set
> source scrambling

Hmm, what happens in this *ERROR* case?

> [ 1145.934277] [drm:intel_hdmi_handle_sink_scrambling] Shashank: Setting
> sink scrambling=1 tmds=1 for enc:DDI C connector:HDMI-A-2
> 
> The only difference is, I was using an old intel_drv.so library. This lib
> comes with X package I guess, as its location is
> (/usr/lib/xorg/modules/drivers/intel_drv.so)

This really shouldn't depend on user space, except for choosing the mode. Can you post a full dmesg log for both modesets. Maybe there is some slight difference between the modes that we're missing.

(In reply to shashank.sharma@intel.com from comment #26)
> enc:DDI C connector:HDMI-A-2

The tests I did where all with DDI-B. Wonder if there are any relevant differences between the B and C connectors.

(In reply to Ander Conselvan de Oliveira from comment #28)
> (In reply to shashank.sharma@intel.com from comment #26)
> > I was able to get a proper modeset on the said mode (25x16) on same monitor,
> > using both Mint GUI as well as testdisplay.
> > There are 3 files attached with this message:
> > - Modeset 25x14 using Mint-GUI: Modeset 25x14 with GUI
> > - Modeset 25x14 using testdisplay: Modeset 25x14 with testdisplay
> > 
> > The command used in testdisplay was:
> > ./testdisplay -f 241.5,2560,2608,2640,2720,1440,1443,1448,1481 
> > 
> > I also confirmed that:
> > - It was 12 BPC modeset
> > - The scrambling and high tmds clock was enabled during this modeset.
> > [ 1145.592443] [drm:intel_hdmi_compute_config] Shashank: picking bpc to 12
> > for HDMI output
> > [ 1145.593176] [drm:intel_hdmi_handle_sink_scrambling] Shashank: Setting
> > sink scrambling=0 tmds=0 for enc:DDI C connector:HDMI-A-2
> > [ 1145.924969] [drm:intel_ddi_enable_transcoder_func] *ERROR* Shashank: Set
> > source scrambling
> 
> Hmm, what happens in this *ERROR* case?
> 
Don't worry about it, I was using DRM_ERROR(Shashank:) for my logs, there is no error here :)
> > [ 1145.934277] [drm:intel_hdmi_handle_sink_scrambling] Shashank: Setting
> > sink scrambling=1 tmds=1 for enc:DDI C connector:HDMI-A-2
> > 
> > The only difference is, I was using an old intel_drv.so library. This lib
> > comes with X package I guess, as its location is
> > (/usr/lib/xorg/modules/drivers/intel_drv.so)
> 
> This really shouldn't depend on user space, except for choosing the mode.
> Can you post a full dmesg log for both modesets. Maybe there is some slight
> difference between the modes that we're missing.

I also thought so, but this lib names intel-drv.so, which seems specific to our HW, so there could be a relation. I will share the full logs tomorrow, as I don't have access to the board today. 

Meanwhile, can you please give it a try, by just replacing your intel_drv.so with attached one, and try this modeset ? This will help us to focus on right path.

Awaiting update from Luis

I was able to get this issue tested with a HDMI analyzer too. 
Here are the updates:
- I was able to see the issue with the attached library too, on selected mode. 
- The display never fails when using the analyzer. It only fails using real monitor. 
- Scrambling and clock high ratio is getting enabled/set/disabled properly. 
- Bootup and modeset dmesg logs attached.

I think this is a fault with monitor, which is not able to handle this mode at 12BPC (Also, This mode is a non-CEA modes, so not a standard one too)

Created attachment 131297 [details]
Bootup dmesg - Shashank

The issue tracked by this bug (corruption with testdisplay -a) has been fixed by the following commit. I'm moving the remaining issue to bug 101059.

commit 46649d8b6cb876e4f823e741d39959cf6e231e85
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date:   Mon Apr 24 13:47:18 2017 +0300

    drm/i915/glk: Don't allow 12 bpc when htotal is too big

I have confirmed with ACER S277HK monitor, that there is no corruption seen with testdisplay with Ander's patch (except the failure on non CEA mode 25x14, which we decided is a monitor's issue).

- Shashank