Created attachment 117244 [details]
intel-reg-dumper

Created attachment 117245 [details]
edid file

Created attachment 117246 [details]
xrandr --verbose

Created attachment 117247 [details]
xorg log

Does i915.enable_ips=0 help at all?

(In reply to Jesse Barnes from comment #5)
> Does i915.enable_ips=0 help at all?

Same symptoms were observed with i915.enable_ips=0.  Kernel is drm-intel-nightly 4.2.0-994.201508010158

Hi Tom,
Please let me know the status of few feature while you get this:

sudo cat /sys/kernel/debug/dri/0/i915_edp_psr_status

sudo cat /sys/kernel/debug/dri/0/i915_fbc_status

sudo cat /sys/kernel/debug/dri/0/i915_ips_status

Thanks,
Rodrigo.

(In reply to Rodrigo Vivi from comment #7)
> Hi Tom,
> Please let me know the status of few feature while you get this:
> 
> sudo cat /sys/kernel/debug/dri/0/i915_edp_psr_status
> 
> sudo cat /sys/kernel/debug/dri/0/i915_fbc_status
> 
> sudo cat /sys/kernel/debug/dri/0/i915_ips_status
> 
> Thanks,
> Rodrigo.

Hi Rodrigo - those directories (beyond /sys/kernel) don't exist on my system.  Do I need to enable some kind of additional logging?

Thanks

Hi,
I think I'm running into the same problem on my machine.  But in my case it only happens after the screen goes to sleep (locking in gnome) and sometimes it stays completely black instead of flickering.  You can also see that it renders some garbage from time to time.

https://www.youtube.com/watch?v=YL_9IRsx8Lo

I'm using the kernel packages from Arch Linux's repositories and it only started happening with version 4.2 (which is on Arch's testing repo right now).  It works fine with 4.1.6 (in the core repo) except for occasional 1 frame blackouts.


System information:
 - Architecture and kernel: 4.2.0-3-ARCH #1 SMP PREEMPT Fri Sep 4 20:59:11 UTC 2015 x86_64 GNU/Linux
 - Distribution: Arch Linux
 - Laptop model: Razer Blade 14" (2015)
 - Laptop Screen: (I don't know how to check this :?)
 - Display Conenctor: eDP

I don't see any errors in any of my logs when this happens.  Is there any debug setting I can use that can help you get more information?

I'd like to get an intel_reg dump output ('intel_reg dump' replaces intel_reg_dumper in recent http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/) for both before and after loading i915. Alternatively, with i915.modeset=0 and i915.modeset=1. It should be interesting to see the difference in register values for both cases.

(In reply to Jani Nikula from comment #10)
> I'd like to get an intel_reg dump output ('intel_reg dump' replaces
> intel_reg_dumper in recent
> http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/) for both before and
> after loading i915. Alternatively, with i915.modeset=0 and i915.modeset=1.
> It should be interesting to see the difference in register values for both
> cases.

Hi Jani, I am away from the laptop right now but should be able to provide the additional information in a few days.

Is there any guide I can follow to dump the registers before the module is loaded?  I did a quick test passing `break=postmount` to the kernel and chrooting into the rootfs but I couldn't manage to get intel_reg to work like this.

Same problem here on the Pentium brodwell GT1 model (TopStar U731).

Does it affect any kernel ?

(In reply to Jani Nikula from comment #10)
> I'd like to get an intel_reg dump output ('intel_reg dump' replaces
> intel_reg_dumper in recent
> http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/) for both before and
> after loading i915. Alternatively, with i915.modeset=0 and i915.modeset=1.
> It should be interesting to see the difference in register values for both
> cases.

I've uploaded two files:
 - i915.modeset0.txt
 - i915.modeset1.txt

Both contain the output of the command "intel_reg dump", one with i915.modeset=0, one with i915.modeset=1.

intel-gpu-tools is version 1.11.  Kernel is drm-intel-next, 4.2.0-997-generic #201509120200 SMP Sat Sep 12 02:02:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux.

Created attachment 118383 [details]
intel_reg dump with i915.modeset=0

Created attachment 118384 [details]
intel_reg dump with i915.modeset=1

If it helps, this is the output of intel_reg dump before and after it happens for me.  This is the sequence:

1) Boot into a gnome 3 desktop  (everything works fine)
2) intel_reg dump > intel_reg-dump-ok
3) Lock the screen with gnome (turns off the display)
4) Unlock the screen (here I start getting the flickering)
5) intel_reg dump > intel_reg-dump-flickering

Created attachment 118538 [details]
intel_reg dump before the flicker happens

Created attachment 118539 [details]
intel_reg dump while the flicker is happening

(In reply to Oscar Morante from comment #17)
> If it helps, this is the output of intel_reg dump before and after it
> happens for me.  This is the sequence:
> 
> 1) Boot into a gnome 3 desktop  (everything works fine)
> 2) intel_reg dump > intel_reg-dump-ok
> 3) Lock the screen with gnome (turns off the display)
> 4) Unlock the screen (here I start getting the flickering)
> 5) intel_reg dump > intel_reg-dump-flickering

Oscar, please add drm.debug=14 module parameter, and attach dmesg all the way from boot to repeating the above (no need to redo the dumps, just 1,3,4). Make sure you capture the dmesg for a sequence that reproduces the issue. Thanks.

Created attachment 118563 [details]
dmesg with drm.debug=14 (boot -> gnome -> lock -> unlock -> flicker)

There you go.

Created attachment 118564 [details]
dmesg with drm.debug=14 (boot -> gnome -> lock -> unlock -> flicker)

Oops! I mixed up the files.  This is the good one.

I received an update from Arch Linux and now instead of flickering it stays completely black (but it turns on).

[2015-10-08 08:53] [ALPM] upgraded xf86-video-intel (1:2.99.917+472+gf0fd4d5-1 -> 1:2.99.917+476+g4e668dd-1)

The Arch package doesn't apply any patches and it get's the source straight from git, notice the git SHA's between the "+g" and "-1".  I'll upload more debug logs later.

Nevermind, I went to capture the logs and now I get the flicker every time... I guess it was just coincidence.

Reverting these commits "fixes" the problem on my machine :)

  - https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/patch/?id=4e96c97742f4201edf1b0f8e1b1b6b2ac6ff33e7
  - https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/patch/?id=5fa836a9d85975c5f0f1219669523c1f0ac64349

Great news Oscar Morante !

Yes, I hope it help to find a proper fix :)

(In reply to Oscar Morante from comment #25)
> Reverting these commits "fixes" the problem on my machine :)
> 
>   -
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/patch/
> ?id=4e96c97742f4201edf1b0f8e1b1b6b2ac6ff33e7
>   -
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/patch/
> ?id=5fa836a9d85975c5f0f1219669523c1f0ac64349

commit 4e96c97742f4201edf1b0f8e1b1b6b2ac6ff33e7
Author: Mika Kahola <mika.kahola@intel.com>
Date:   Wed Apr 29 09:17:39 2015 +0300

    drm/i915: eDP link training optimization

commit 5fa836a9d85975c5f0f1219669523c1f0ac64349
Author: Mika Kahola <mika.kahola@intel.com>
Date:   Wed Apr 29 09:17:40 2015 +0300

    drm/i915: DP link training optimization

Cc: Mika.

Please try this patch:

http://patchwork.freedesktop.org/patch/msgid/1446223656-27792-1-git-send-email-ville.syrjala@linux.intel.com

I'm having the same problem on 4.2.x and 4.3 and patch suggested by Jani Nikula doesn't help. Reverting the patches mentioned by Oscar Morante fixes the problem for both 4.2.x and 4.3

Created attachment 119983 [details] [review]
Make DP fast link training option as module parameter

I wasn't able to replicate this issue of flickering screen with the HW that I had available. However, that doesn't rule out the fact that there truly is a problem. It seems that there are panels out there that simply doesn't like to start DP link training with non-zero values. 

The patch here makes this fast link training feature as one module parameter (/sys/module/i915/parameters/enable_dp_flt) so you can enable or disable the feature depending on panel support. By default this feature is disabled. The patch applies to drm-intel-nightly.

Please, give this patch a try and report back with dmesg log if the problem still exists.

I was experiencing the same problem after upgrading to Kubuntu 15.10, kernel 4.2.0-18-generic (Dell m3800); the flickering happens if I switch from a lower resolution than the maximal one, 3200x1800, e.g., 1920x1080).

I tried to apply the latest patch, but it does not apply since I guess it's too new for the sources of 4.2.0-18-generic.

However, reverting the two commits as mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=91393#c25 fixes the problem for me as well!

I applied the patch and it resolved my flickering problem.

Assigning to our QA for verification

(In reply to Tom Furniss from comment #33)
> I applied the patch and it resolved my flickering problem.

Thank you for testing! Unfortunately, it turned out we cannot upstream that patch as we do not want to add additional module parameters. Instead, we need to come up with another kind of solution.

Created attachment 120109 [details] [review]
DP configuration check

This patch adds additional test and disables fast link training feature if DP link parameters such as link bandwidth, rate selection, lane count, port clock and bpp. If one of these parameter change the fast link training is disabled and link is retrained with the link training parameters starting from zero values. Please, give this patch a go and report back with dmesg if flickering still exists.

Lowering the priority. 
This is not blocking our work and we haven't been able to reproduce the problem on our side.

(In reply to Mika Kahola from comment #36)
> Created attachment 120109 [details] [review] [review]
> DP configuration check
> 
> This patch adds additional test and disables fast link training feature if
> DP link parameters such as link bandwidth, rate selection, lane count, port
> clock and bpp. If one of these parameter change the fast link training is
> disabled and link is retrained with the link training parameters starting
> from zero values. Please, give this patch a go and report back with dmesg if
> flickering still exists.

To which kernel should this patch be applied?

(In reply to Lorenzo Bettini from comment #38)
> (In reply to Mika Kahola from comment #36)
> > Created attachment 120109 [details] [review] [review] [review]
> > DP configuration check
> > 
> > This patch adds additional test and disables fast link training feature if
> > DP link parameters such as link bandwidth, rate selection, lane count, port
> > clock and bpp. If one of these parameter change the fast link training is
> > disabled and link is retrained with the link training parameters starting
> > from zero values. Please, give this patch a go and report back with dmesg if
> > flickering still exists.
> 
> To which kernel should this patch be applied?

This should apply to drm-intel-nightly. I received a feedback concerning this patch and I updated it. An updated version can be found

https://patchwork.freedesktop.org/patch/66697/

I see significant flickering for about 2-3 minutes every time I resume from RAM in Fedora 23 (kernel 4.2.6-300.fc23.x86_64). The problem was also present in Fedora 22.

- External monitor (Crossover brand), connected via DP
- Intel HD Graphics 4600

Strangely, sometimes opening a terminal window with black background (even in non-fullscreen mode) stops the flickering, but if I minimize the window again, the flickering resumes.

I don't see anything strange in the logs.

That is a bit strange. Could you provide a dmesg log with the option drm.debug=0xe?

(In reply to Mika Kahola from comment #36)
> Created attachment 120109 [details] [review] [review]
> DP configuration check
> 
> This patch adds additional test and disables fast link training feature if
> DP link parameters such as link bandwidth, rate selection, lane count, port
> clock and bpp. If one of these parameter change the fast link training is
> disabled and link is retrained with the link training parameters starting
> from zero values. Please, give this patch a go and report back with dmesg if
> flickering still exists.

Hi Mika.  Your second patch also fixes the problem for me.  After removing your first patch and applying the second the flickering issue did not recur.

hi, I'm also experiencing bad flickering of my laptop screen.
I have installed xubuntu 15.10 on Acer C740:

a@chrome:~$ sudo lshw -c video
  *-display               
       description: VGA compatible controller
       product: Broadwell-U Integrated Graphics
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 08
       width: 64 bits
       clock: 33MHz
       capabilities: msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: irq:43 memory:e0000000-e0ffffff memory:d0000000-dfffffff ioport:1800(size=64)

a@chrome:~$ uname -a
Linux chrome 4.2.0-19-generic #23-Ubuntu SMP Wed Nov 11 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

But today display was blanked after 15 minutes of inactivity and when I woken it up I saw no more flickering and this kernel message:
Dec  5 10:16:48 chrome kernel: [ 3708.390613] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training

please suggest a way (usingn a kernel parameter) to disable link training until a bugfix is backported

(In reply to flux242 from comment #43)
> hi, I'm also experiencing bad flickering of my laptop screen.
> I have installed xubuntu 15.10 on Acer C740:
> 
> a@chrome:~$ sudo lshw -c video
>   *-display               
>        description: VGA compatible controller
>        product: Broadwell-U Integrated Graphics
>        vendor: Intel Corporation
>        physical id: 2
>        bus info: pci@0000:00:02.0
>        version: 08
>        width: 64 bits
>        clock: 33MHz
>        capabilities: msi pm vga_controller bus_master cap_list rom
>        configuration: driver=i915 latency=0
>        resources: irq:43 memory:e0000000-e0ffffff memory:d0000000-dfffffff
> ioport:1800(size=64)
> 
> a@chrome:~$ uname -a
> Linux chrome 4.2.0-19-generic #23-Ubuntu SMP Wed Nov 11 11:39:30 UTC 2015
> x86_64 x86_64 x86_64 GNU/Linux
> 
> But today display was blanked after 15 minutes of inactivity and when I
> woken it up I saw no more flickering and this kernel message:
> Dec  5 10:16:48 chrome kernel: [ 3708.390613] [drm:intel_dp_start_link_train
> [i915]] *ERROR* failed to enable link training
> 
> please suggest a way (usingn a kernel parameter) to disable link training
> until a bugfix is backported

I need to add some additional info. Ive managed to reproduce the case when after screen blanking there's no flickering anymore. I start the 'xset dpms force off' command to blank the screen and after a pause I press a button to wake it up. Below is a pastebin when flickering persist after waking up:
http://pastebin.com/fuY57tMH

And here is a pastebin when the flickering is gone after waking up:
http://pastebin.com/4gGMTycL

It was really difficult to reproduce the case when the flicker is gone

Just wanted to summarise the progress against the original problem, which may or may not be related to some of these other issues, and to add some test detail.

The original problem was a continually flickering screen, starting part-way through boot and prior to the login screen, and affected the extended display port of the laptop screen only, not external monitors.

Mika's original patch fixed this issue, removing the flicker, but during QA Mika was asked to modify it to remove kernel parameters.  Mika's revised (second) patch also resolved the issue.

With both of Mika's patches there were still some graphics issues:
1) Initial blank screen on boot.
2) Occasional blinking of the graphics, ranging from every few seconds to every 2-3 minutes.  The blink lasted only a fraction of a second, and whilst noticeable it wasn't a major concern.
3) The flickering returned when resuming from sleep.

Issue 1 was a relatively common brightness issue, and was resolved by using kernel parameter acpi_osi=linux, and running this command automatically on startup, "setpci -s 00:02.0 F4.B=00".  This also resolved issue 2, removing the occasional blink.

Issue 3 remains.

I applied the latest patch from Mika on top of drm-intel-nightly and it's been working great for the last couple of days.  Suspending or changing resolution doesn't cause flicker anymore, and it also seems to have fixed the ocassional one frame blackout I had before (which still happens on windows btw).

I didn't need any extra configuration like Tom, it just worked out of the box.  I'll let you know if something changes but it seems to be fixed on my system.

Thanks!

(In reply to Oscar Morante from comment #46)
> I applied the latest patch from Mika on top of drm-intel-nightly and it's
> been working great for the last couple of days.  Suspending or changing
> resolution doesn't cause flicker anymore, and it also seems to have fixed
> the ocassional one frame blackout I had before (which still happens on
> windows btw).
> 
> I didn't need any extra configuration like Tom, it just worked out of the
> box.  I'll let you know if something changes but it seems to be fixed on my
> system.
> 
> Thanks!

Great to hear that the patch worked out for you!

Created attachment 120389 [details] [review]
Check if DP training set applied ok

Tom reported that flickering occurs when resuming back from the sleep. When resuming we are already trained the DP link and most probably reusing the DP link parameters when retraining the link. It may be possible that setting the DP training pattern fails yielding an error message of "*ERROR* failed to enable link training". This patch introduces a check to the routine that applies the DP training pattern. If this check fails, the link training is restarted by setting the parameters to zero.

The patch applies on top of the latest drm-intel-nightly and requires this https://patchwork.freedesktop.org/patch/66697/ patch to be applied

Created attachment 120480 [details]
Syslog for resume from sleep flickering

Sleep initiated at 13:03.

Created attachment 120481 [details]
dmesg for resume from sleep flickering

Mika - firstly thank you for fixing the original issue, it's great to be able to use the laptop.

I've applied your additional patch and the flickering on resume from sleep continues.  I've uploaded the dmesg and syslog - there is a lot of drm debug in the syslog after the resume from sleep.

I've experienced exactly the same problem, as Tom Furniss described.
Kernel version: 4.2.6-301.fc23.x86_64 
dmesg with drm.debug=14 attached.
I'm failed to apply patches, files structure in drivers/gpu/drm/i915/ is slightly different.
If there is any other options for me to fix issue?

Created attachment 120485 [details]
dmesg with drm.debug=14

(In reply to Andrew Merzlyakov from comment #52)
> I've experienced exactly the same problem, as Tom Furniss described.
> Kernel version: 4.2.6-301.fc23.x86_64 
> dmesg with drm.debug=14 attached.
> I'm failed to apply patches, files structure in drivers/gpu/drm/i915/ is
> slightly different.
> If there is any other options for me to fix issue?

These patches apply to drm-intel-nightly kernel which is a development tree for i915 driver. You can clone the git repository from 

https://01.org/linuxgraphics/documentation/development/source-code

and apply these patches on top of it. I'm afraid, this is the only option at the moment to get these issues fixed. Eventually, these patches will be upstreamed as fixes.

Created attachment 120493 [details] [review]
Disable fast link training when resuming

Tom - thank you for you feedback and logs. I think I need to disable the fast link training feature when resuming from the suspend state. This patch does just that in case of DP or eDP connectors. Please, test this patch if this would provide a solution for this resuming issue.

(In reply to Mika Kahola from comment #54)
> These patches apply to drm-intel-nightly kernel which is a development tree
> for i915 driver. You can clone the git repository from 
> 
> https://01.org/linuxgraphics/documentation/development/source-code
> 
> and apply these patches on top of it. I'm afraid, this is the only option at
> the moment to get these issues fixed. Eventually, these patches will be
> upstreamed as fixes.

well, eventually means it could take halve a year until we got those patches which makes our computers useless. I can also add that on my computer I cannot enable vesa mode and i915.modeset=0 option makes the screen black, i.e. bricks it. Reverting two patches for the ubuntu's 4.2.0.19 kernel like it was described above doesn't help either. I tried to figure out how to apply your patch onto 4.2.0.19 but it seems like training staff was moved out of the intel_dp.c and some files are missing completely, so no luck.

Cloning the 1Gigabyte git repo like you suggest would also mean that I'd need to compile drm driver code with the kernel version that in that repo too right? Or I can copy the gpu/drm/i915 over to my kernel version and it'll work?

> Cloning the 1Gigabyte git repo like you suggest would also mean that I'd
> need to compile drm driver code with the kernel version that in that repo
> too right? Or I can copy the gpu/drm/i915 over to my kernel version and
> it'll work?

Yes, you must rebuild kernel with updated drm driver and applied patches.

(In reply to Mika Kahola from comment #55)
> Created attachment 120493 [details] [review] [review]
> Disable fast link training when resuming
> 
> Tom - thank you for you feedback and logs. I think I need to disable the
> fast link training feature when resuming from the suspend state. This patch
> does just that in case of DP or eDP connectors. Please, test this patch if
> this would provide a solution for this resuming issue.

Hi Mika

Just a quick update as I'm away from my test laptop until the end of the week. The patch did not resolve the issue, though interestingly the flickering appears from the time the suspend sequence starts rather than on resume (the screen starts flickering before it turns off).

I'll test more thoroughly and post logs at the weekend.

patch https://patchwork.freedesktop.org/patch/66697/ DOESN'T solve the flickering problem on my computer.

What I did:
1. installed generic kernel and headers from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-12-24-wily/
2. get the sources from the git://anongit.freedesktop.org/drm-intel branch drm-intel-nightly (commit number: ec0382c73cb1adc972bebdd94afad3f0ea117114)
3. applied the patch https://patchwork.freedesktop.org/patch/66697/
4. compiled the i915 driver and installed it:

mykern=${1:-$(uname -r)}
cp /usr/src/linux-headers-$mykern/Module.symvers .

# Prep tree
cp /boot/config-$mykern ./.config
make oldconfig
make prepare
make modules_prepare

# Build only the needed directories
make SUBDIRS=drivers/gpu/drm/i915 modules
[ -s /lib/modules/$mykern/kernel/drivers/gpu/drm/i915/i915.ko.orig ] || sudo cp /lib/modules/$mykern/kernel/drivers/gpu/drm/i915/i915.ko{,.orig}
sudo cp drivers/gpu/drm/i915/i915.ko /lib/modules/$mykern/kernel/drivers/gpu/drm/i915/
5. reboot

But. Now with the kernel 4.4.xx if I run 'xset dpms force off' just after the boot then the flicker is gone.

grep of the last boot syslog:
$ grep drm /tmp/syslog 
Dec 24 11:29:49 chrome kernel: [    2.028119] [drm] Initialized drm 1.1.0 20060810
Dec 24 11:29:49 chrome kernel: [    2.066980] [drm] Memory usable by graphics device = 4096M
Dec 24 11:29:49 chrome kernel: [    2.066985] [drm] Replacing VGA console driver
Dec 24 11:29:49 chrome kernel: [    2.067495] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
Dec 24 11:29:49 chrome kernel: [    2.067498] [drm] Driver supports precise vblank timestamp query.
Dec 24 11:29:49 chrome kernel: [    2.067501] [drm] failed to find VBIOS tables
Dec 24 11:29:49 chrome kernel: [    2.210886] [drm] Initialized i915 1.6.0 20151218 for 0000:00:02.0 on minor 0
Dec 24 11:29:49 chrome kernel: [    2.211478] fbcon: inteldrmfb (fb0) is primary device
Dec 24 11:29:49 chrome kernel: [    3.021978] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to enable link training
Dec 24 11:29:49 chrome kernel: [    3.025516] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel equalization
Dec 24 11:29:49 chrome kernel: [    3.206466] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
Dec 24 11:30:13 chrome kernel: [   29.162270] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to enable link training

Created attachment 120678 [details]
syslog for sleep/resume flickering issue

Mika - this is the syslog for the flickering on resume from sleep, after applying your latest patch (https://bugs.freedesktop.org/attachment.cgi?id=120493)

I do fairly consistently see a single flicker after requesting sleep, and before the laptop sleeps.  This may or may not be the flickering issue, so I can't be certain whether the problem starts on requesting sleep mode, or on resuming from sleep.

Thank you Tom for the syslog. From the log the DP link training is completed but for some reason the DP channel equalization fails. At this point we request to do link training once again and now first we try first the drive current and pre-emphasis levels from the previous link training. Instead of reusing these values, we should restart the link training with zero drive current and pre-emphasis levels. This is fixed at the 3rd patch of this series. 

Please, try out this series of patches on top of the drm-intel-nighly and report back.

https://patchwork.freedesktop.org/patch/69394/
https://patchwork.freedesktop.org/patch/69395/
https://patchwork.freedesktop.org/patch/69396/

flux242 seems to have a clock recovery issue. This fix may provide a solution for that as well.

Created attachment 120818 [details]
syslog after three patches and returned flicker

Hi Mika.

I seem to have regressed, and the flicker has returned.  I took a new branch of intel-drm-nightly, and applied the three patches in the sequence you provided, but the flickering has returned and is consistent on every boot.

Previously I had applied patches from this defect against a version of intel-drm-next from late November.

The attached files are the syslog and dmesg.

Created attachment 120819 [details]
dmesg after three patches and returned flicker

> https://patchwork.freedesktop.org/patch/69394/
> https://patchwork.freedesktop.org/patch/69395/
> https://patchwork.freedesktop.org/patch/69396/
> 
> flux242 seems to have a clock recovery issue. This fix may provide a
> solution for that as well.

three patches above (without the https://patchwork.freedesktop.org/patch/66697/) do not help

Seeing the video again and based on recent issues I faced I believe this could be watermark related...
So, could you please apply http://patchwork.freedesktop.org/patch/69417/
and boot with i915.enable_watermark=0 and let us know what happens?

(In reply to Rodrigo Vivi from comment #65)
> Seeing the video again and based on recent issues I faced I believe this
> could be watermark related...
> So, could you please apply http://patchwork.freedesktop.org/patch/69417/
> and boot with i915.enable_watermark=0 and let us know what happens?

The watermark patch did not affect the symptoms of this problem, Rodrigo.  I think Mika is on the right track, having solved the initial problem (persistent flickering) by modifying the eDP link training.  The remaining problem is that the flickering recurs when the display resumes from sleep.

> think Mika is on the right track, having solved the initial problem
> (persistent flickering) by modifying the eDP link training.  The remaining
> problem is that the flickering recurs when the display resumes from sleep.

in my case flickering occur just after reboot (and this is not the same flickerin art like in the video). Then I need to run 'xset dpms force off' command in the terminal at least once or many times until flickering is gone. Afterwards I see no flickering any longer even if it resumes from sleep. I can add that on the same hardware chromiumos works flawlessly.

Created attachment 120893 [details] [review]
DP debugging

Tom, I would bother you again to provide some debugging info. From the dmesg you sent it seems that you are experiencing a lot of hpd interrupts. When that happens the driver checks if the DP channel equalization is still ok. On your case, channel equalization is not ok yielding DP link to be retrained. Of course, this causes flickering as the DP link is broken for some time. The patch I'm proposing for debugging purposes applies on top of the latest -nightly and on top of these previous patches 

https://patchwork.freedesktop.org/patch/69394/
https://patchwork.freedesktop.org/patch/69395/
https://patchwork.freedesktop.org/patch/69396/

The patch adds more verbose debug information on channel equalization and limits the DP link retraining to 5. After 5 attempts to retrain the link you probably end up having a non-flickering display or a black screen. Please, report back with dmesg.

Created attachment 120919 [details]
syslog for 3 patches with increased debug

Hi Mika

No problem.  I applied the following patches to the latest drm-intel-nightly:
https://patchwork.freedesktop.org/patch/69394/
https://patchwork.freedesktop.org/patch/69395/
https://patchwork.freedesktop.org/patch/69396/
https://bugs.freedesktop.org/attachment.cgi?id=120893

As expected, flickering is still present.  syslog attached.

The last patch that fixed the issue was this:
https://patchwork.freedesktop.org/patch/66697/
Is there a reason we're not using it now?

Created attachment 120920 [details]
dmesg for 3 patches with increased debug

(In reply to Tom Furniss from comment #69)
> Created attachment 120919 [details]
> syslog for 3 patches with increased debug
> 
> Hi Mika
> 
> No problem.  I applied the following patches to the latest drm-intel-nightly:
> https://patchwork.freedesktop.org/patch/69394/
> https://patchwork.freedesktop.org/patch/69395/
> https://patchwork.freedesktop.org/patch/69396/
> https://bugs.freedesktop.org/attachment.cgi?id=120893
> 

Thank you Tom for providing a log. The issue still persists and you keep receiving a lot of short hotplug detection pulses.

> As expected, flickering is still present.  syslog attached.
> 
> The last patch that fixed the issue was this:
> https://patchwork.freedesktop.org/patch/66697/
> Is there a reason we're not using it now?
During the patch review I received comments that I should move the idea of tracking the config changes to its current location in patch https://patchwork.freedesktop.org/patch/69394/

If you have time, it would be interesting to know if you apply this patch https://patchwork.freedesktop.org/patch/66697/
on top of current -nightly and check if it still fixes the flickering.

Hi Mika

Yes, applying patch 66697 against the latest intel-drm-nightly does still resolve the issue.

Also reported in (https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1522922).

(In reply to Tom Furniss from comment #72)
> Hi Mika
> 
> Yes, applying patch 66697 against the latest intel-drm-nightly does still
> resolve the issue.

Actually, within 10 seconds of posting that message the flickering started again, and has continued through multiple reboots.  So I think I can safely say that the last version of the kernel patched with 66697 that resolved the issue was 4.3.0 rc3.

It seems that we have something else causing a regression than this link training optimization feature. Any chance to do bisecting with patch 66697 applied?

Created attachment 121148 [details]
In my case it crashes the PC. Got a kdump.

see also https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1535048

I have a similar problem since 2014.

https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1271704

Toshiba Satellite S75-A7334, i7-4700MQ.

*-display               
     descrição: VGA compatible controller
     produto: 4th Gen Core Processor Integrated Graphics Controller
     fabricante: Intel Corporation
     ID físico: 2
     informações do barramento: pci@0000:00:02.0
     versão: 06
     largura: 64 bits
     clock: 33MHz
     capacidades: msi pm vga_controller bus_master cap_list rom
     configuração: driver=i915 latency=0
     recursos: irq:45 memória:b2000000-b23fffff memória:a0000000-afffffff porta de E/S:6000(tamanho=64)

Ubuntu 15.10.
Linux 3.13.0-37-generic #64-Ubuntu
intel-linux-graphics-installer_1.2.1-0intel2_amd64.deb

filename:       /lib/modules/3.13.0-37-generic/kernel/drivers/gpu/drm/i915/i915.ko
license:        GPL and additional rights
description:    Intel Graphics
author:         Tungsten Graphics, Inc.
license:        GPL and additional rights
srcversion:     594AF6054E9069A37423B0F
vermagic:       3.13.0-37-generic SMP mod_unload modversions 
signer:         Magrathea: Glacier signing key
sig_key:        2C:B1:13:3B:35:F9:5A:9E:24:DE:AB:EE:B1:2B:A4:49:BC:BA:BB:C9

Almost of time the screen turns grey colors and stops flickering. Then, I have to try change screen resolution many times until colors are back, and the flickering.

I have tried several screen resolutions and frequencies, including the configuration that works fine with graphic Gallium 0.4 on llvmpipe (LLVM 3.6, 256 bits), that I got when I boot in recovery mode, choose failsafeX and I stop the process with CTRL+C just after the X error.

I reinstalled Ubuntu 15.10 from a DVD iso. Problem fixed.
Linux toshibaS75 4.2.0-27-generic #32-Ubuntu SMP Fri Jan 22 04:49:08 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

(In reply to jlrivitti from comment #78)
> I reinstalled Ubuntu 15.10 from a DVD iso. Problem fixed.
> Linux toshibaS75 4.2.0-27-generic #32-Ubuntu SMP Fri Jan 22 04:49:08 UTC
> 2016 x86_64 x86_64 x86_64 GNU/Linux

I've just tried 4.2.0-27-generic and the flickering is still there

I tested ubuntu Xenial beta, which has the following kernel

Linux ubuntu 4.4.0-9-generic #24-Ubuntu SMP Mon Feb 29 19:33:19 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

The bug is still there...

it happens not only if you decrease the resolution, but also with the higher resolution after resuming from screen saver.

Started a few weeks ago to get this with my HSW 4200U laptop. Dunno the exact date, but I've been using drm-intel-nightly all the time, so presumably since PSR was default enabled.

/sys/kernel/debug/dri/0/i915_edp_psr_status
Sink_Support: yes
Source_OK: yes
Enabled: yes
Active: yes
Busy frontbuffer bits: 0x000
Re-enable work scheduled: no
Main link in standby mode: no
HW Enabled & Active bit: yes
Performance_Counter: 50578

/sys/kernel/debug/dri/0/i915_fbc_status
FBC disabled: FBC enabled (active or scheduled)
Compressing: yes

/sys/kernel/debug/dri/0/i915_ips_status
Enabled by kernel parameter: yes
Currently: enabled

I've tried with the v6 "Disable fast link training if DP config changes" patchset applied, no apparent change.

Created attachment 122338 [details] [review]
no-flicker-after-dpms-4.5.patch

Kernel 4.5.0 still has this bug for me. I managed to narrow down the patch to remedy the flickering to just one hunk though.

(In reply to Pavel Procopiuc from comment #82)
> Created attachment 122338 [details] [review] [review]
> no-flicker-after-dpms-4.5.patch
> 
> Kernel 4.5.0 still has this bug for me. I managed to narrow down the patch
> to remedy the flickering to just one hunk though.

Did you try these patches?
https://patchwork.freedesktop.org/patch/69394/
https://patchwork.freedesktop.org/patch/69395/
https://patchwork.freedesktop.org/patch/69396/

In addition, if you could provide your dmesg log as well. I would be interested to know if we fail on clock recovery or not.

I tried them way back in January with no visible difference, flickering still appears after laptop panel turns off and back on.

Regarding dmesg, can you please tell me for which kernel you want to see it (intel-drm-next/vanilla), with those patches or without and which additional kernel debugging options should be enabled?

(In reply to Pavel Procopiuc from comment #84)
> I tried them way back in January with no visible difference, flickering
> still appears after laptop panel turns off and back on.
> 
> Regarding dmesg, can you please tell me for which kernel you want to see it
> (intel-drm-next/vanilla), with those patches or without and which additional
> kernel debugging options should be enabled?

If you can run dmesg with drm-intel-nightly kernel and if you could apply those patches too, so we could get more debug info as well.

Created attachment 122363 [details]
dmesg-intel-nightly-patches

Here it is, it's from drm-intel kernel on commit 9f8709f + 3 patches you provided. I took a dmesg right after boot (while there was no flickering) and then did "xset dpms force off", panel turned off, I waited for a couple of seconds, did some input activity, panel turned on and flicker appeared, I waited for about 30 seconds and took another dmesg, but there were no changes between them. Plus I don't see too much debug information in the dmesg. Am I missing some kernel parameter?

(In reply to Pavel Procopiuc from comment #86)
> Created attachment 122363 [details]
> dmesg-intel-nightly-patches
> 
> Here it is, it's from drm-intel kernel on commit 9f8709f + 3 patches you
> provided. I took a dmesg right after boot (while there was no flickering)
> and then did "xset dpms force off", panel turned off, I waited for a couple
> of seconds, did some input activity, panel turned on and flicker appeared, I
> waited for about 30 seconds and took another dmesg, but there were no
> changes between them. Plus I don't see too much debug information in the
> dmesg. Am I missing some kernel parameter?

Sorry, I forgot to mention that you need to include the following kernel parameters in order to enable debugging info. So, can you rerun the test with these parameters in place, please

drm.debug=0x1e log_buf_len=1M

Created attachment 122405 [details]
dmesg-before-flicker

Created attachment 122406 [details]
dmesg-after-flicker

Here are the two dmesg dumps, same kernel, same patches, but with the options you mentioned. They are different this time.

One thing I also noticed is that there is not only flicker, but sometimes old screen content is used for a moment. Like in virtual console cursor suddenly jumps back where it was moments ago and then back to its current location. These jumps only happen during flicker.

Created attachment 122497 [details] [review]
Cache DP signal levels

In your case, when DP link is retrained with the settings from previous link training the clock recovery fails. This leads into a situation where link training is started from scratch. However, now the clock recovery seems to be happy with the lower voltage swing and pre-emphasis settings than with the first iteration round. You may experience flickering due to this as the physical link may require higher voltage swing or pre-emphasis than provided.

We could try the following trick here. Let's cache the signal levels and in case of link retraining we retrain the link until we have reached the previously trained signal levels and clock recovery is reached.

Please, give this a go on top of the latest drm-intel-nightly with these 3 patches applied. Dmesg logs are appreciated too ;)

Created attachment 122517 [details]
dmesg after 0004-drm-i915-Cache-DisplayPort-link-signal-levels.patch

It works, I'm not seeing any flicker or repainting issues anymore. Thank you! I'm still attaching the dmesg. This one covers messages from the boot until about 30 seconds after DPMS.

I was applying patches against 6f78897 of drm-intel. All 4 patches also apply against vanilla 4.5.0 also fixing the issue.

Great that the patches worked out for you. I guess its time to upstream these patches.

(In reply to Mika Kahola from comment #93)
> Great that the patches worked out for you. I guess its time to upstream
> these patches.

It would be great if you could upstream it before Ubuntu Xenial is released.

Are these patches in latest-drm-nightly already?

(In reply to thoehlig from comment #95)
> Are these patches in latest-drm-nightly already?

Not yet. These patches needs to be reviewed first.

Still having the issue of flickering on my HSW eDP with drm-intel-nightly + v6 patchset + Cache DP signal levels.

Then again my flickering is different and likely a different issue. It's black flashes of the entire screen, for about the same duration yet at seemingly random intervals (incl. when idling) and much less frequent.

So, eight months since this has been reported and you guys can't even be bothered to at least revert the changes that caused this originally?  The normal kernel is completely unusable on my machine due to this issue (Dell XPS 15 (9530)) so I have been forced to run the LTS kernel for the past several months.

Has the latest patch even been sent to the list? At least I can't find it.

(In reply to Timo Aaltonen from comment #99)
> Has the latest patch even been sent to the list? At least I can't find it.

Indeed, the patch wasn't on the list. Now you can review it from 

https://patchwork.freedesktop.org/patch/82206/

However, it seems that there are HW's out there that still have flickering issues.

I am on a Dell XPS 13 9350 FullHD and I do have the Flicker under Kernel 4.4.0-18 on Ubuntu 16.04 LTS. 

I am a bit lost in all these comments, could someone tell me what patch I can try to see if one of your patches has affect on my setup? 


There is also a Bug report related to this one over here:

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

(In reply to nhellwege from comment #101)
> I am a bit lost in all these comments, could someone tell me what patch I
> can try to see if one of your patches has affect on my setup? 

These 4:
https://patchwork.freedesktop.org/patch/69394/
https://patchwork.freedesktop.org/patch/69395/
https://patchwork.freedesktop.org/patch/69396/
https://patchwork.freedesktop.org/patch/82206/

(In reply to Pavel Procopiuc from comment #102)
> (In reply to nhellwege from comment #101)
> > I am a bit lost in all these comments, could someone tell me what patch I
> > can try to see if one of your patches has affect on my setup? 
> 
> These 4:
> https://patchwork.freedesktop.org/patch/69394/
> https://patchwork.freedesktop.org/patch/69395/
> https://patchwork.freedesktop.org/patch/69396/
> https://patchwork.freedesktop.org/patch/82206/

On top of drm-intel-nightly or Ubuntu-4.4.0-18?

Thanks!

(In reply to nhellwege from comment #103)
> (In reply to Pavel Procopiuc from comment #102)
> > (In reply to nhellwege from comment #101)
> > > I am a bit lost in all these comments, could someone tell me what patch I
> > > can try to see if one of your patches has affect on my setup? 
> > 
> > These 4:
> > https://patchwork.freedesktop.org/patch/69394/
> > https://patchwork.freedesktop.org/patch/69395/
> > https://patchwork.freedesktop.org/patch/69396/
> > https://patchwork.freedesktop.org/patch/82206/
> 
> On top of drm-intel-nightly or Ubuntu-4.4.0-18?
> 
> Thanks!

These applies to drm-intel-nightly.

(In reply to nhellwege from comment #103)
> On top of drm-intel-nightly or Ubuntu-4.4.0-18?

Can't really say anything about 4.4, I successfully applied them on top of 4.5, 4.6 and drm-nightly when I was checking them.

(In reply to Mika Kahola from comment #100)
> (In reply to Timo Aaltonen from comment #99)
> > Has the latest patch even been sent to the list? At least I can't find it.
> 
> Indeed, the patch wasn't on the list. Now you can review it from 
> 
> https://patchwork.freedesktop.org/patch/82206/
> 
> However, it seems that there are HW's out there that still have flickering
> issues.

Hi,

today i tested kernel drm-intel-nightly (5f13745078ab86d9833a181980afc7888157a9a4) with patch 82206 applied and i still have the issue that sometimes my external screens turn to black and recover bit later. Sometimes one does not recover at all or is flickering afterwards.

The dmesg log still shows some "[drm:gen8_de_irq_handler] The master control interrupt lied (SDE)!" messages.

More sys infos here.
https://bugs.freedesktop.org/show_bug.cgi?id=94479

(In reply to Pavel Procopiuc from comment #105)
> (In reply to nhellwege from comment #103)
> > On top of drm-intel-nightly or Ubuntu-4.4.0-18?
> 
> Can't really say anything about 4.4, I successfully applied them on top of
> 4.5, 4.6 and drm-nightly when I was checking them.

So I applied all patches to drm-intel-next-2016-03-30 (tag from drm-intel-nightly).  I still do have my specific error (underrun FIFO), which apparently results into black screen flickering: 
 
[    1.307318] [drm] Finished loading i915/skl_dmc_ver1.bin (v1.26)
[    1.332959] [drm] Initialized i915 1.6.0 20160330 for 0000:00:02.0 on minor 0
[    2.711324] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[    3.267095] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[   50.860161] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
[   55.077891] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
[   55.333444] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
[  728.412055] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

Thanks anyways, it was worth a try.

btw: The bogus alignment and training clock error was after I recovered from suspend.

*** Bug 94593 has been marked as a duplicate of this bug. ***

Dammit.  Now this regression has made it into the LTS kernel.  Are you guys kidding me?  Is it not possible for the changes that caused this exceptionally annoying regression (as in my computer is now almost entirely unusable) to be removed from the current production kernel, pending a proper fix?????

(In reply to alex from comment #109)
> Dammit.  Now this regression has made it into the LTS kernel.  Are you guys
> kidding me?  Is it not possible for the changes that caused this
> exceptionally annoying regression (as in my computer is now almost entirely
> unusable) to be removed from the current production kernel, pending a proper
> fix?????

My current understanding is that there are multiple causes for flickering. Reverting this patch may solve an issue with one platform. Could you share your dmesg log with drm.debug=0x1e for further analysis, please.

Created attachment 123264 [details]
systemd logs with drm.debug=0x1e for stock 4.5.1 kernel (arch) with flicker after standby

(In reply to Mika Kahola from comment #110)
> (In reply to alex from comment #109)
> > Dammit.  Now this regression has made it into the LTS kernel.  Are you guys
> > kidding me?  Is it not possible for the changes that caused this
> > exceptionally annoying regression (as in my computer is now almost entirely
> > unusable) to be removed from the current production kernel, pending a proper
> > fix?????
> 
> My current understanding is that there are multiple causes for flickering.
> Reverting this patch may solve an issue with one platform. Could you share
> your dmesg log with drm.debug=0x1e for further analysis, please.

Posted.  I rebooted into the stock 4.5.1 kernel (direct from the Arch repository) with drm.debug=0x1e added to the kernel command line, logged in, suspended, resumed, and dumped the log with journalctl.  I took a quick check through and didn't see any messages that indicated any sort of failure after the suspend operation.  However there are a lot of messages in there, so I could have missed something.  What I do know is that after the resume from suspend, I get something on the order of a 2 Hz flicker on the display that looks like the eDP link is flapping - i.e. there is tearing that affects the bottom portion of the display more than the top due to the link going down in the middle of a frame, portions of the display are briefly distorted or colored strangely, etc.  None of this happens on 4.1.21, which is where I will stay until this gets a proper fix in the mainline.

(In reply to alex from comment #112)
> (In reply to Mika Kahola from comment #110)
> > (In reply to alex from comment #109)
> > > Dammit.  Now this regression has made it into the LTS kernel.  Are you guys
> > > kidding me?  Is it not possible for the changes that caused this
> > > exceptionally annoying regression (as in my computer is now almost entirely
> > > unusable) to be removed from the current production kernel, pending a proper
> > > fix?????
> > 
> > My current understanding is that there are multiple causes for flickering.
> > Reverting this patch may solve an issue with one platform. Could you share
> > your dmesg log with drm.debug=0x1e for further analysis, please.
> 
> Posted.  I rebooted into the stock 4.5.1 kernel (direct from the Arch
> repository) with drm.debug=0x1e added to the kernel command line, logged in,
> suspended, resumed, and dumped the log with journalctl.  I took a quick
> check through and didn't see any messages that indicated any sort of failure
> after the suspend operation.  However there are a lot of messages in there,
> so I could have missed something.  What I do know is that after the resume
> from suspend, I get something on the order of a 2 Hz flicker on the display
> that looks like the eDP link is flapping - i.e. there is tearing that
> affects the bottom portion of the display more than the top due to the link
> going down in the middle of a frame, portions of the display are briefly
> distorted or colored strangely, etc.  None of this happens on 4.1.21, which
> is where I will stay until this gets a proper fix in the mainline.

It seems that you have similar issue than we have seen before. During resume, the display driver tries to use the DP link parameters that was computed during the initial boot. However, the clock recovery is not obtained and hence the DP link is retrained. At this stage, the driver tries with 0 voltage swing and no pre-emphasis. For some reason the clock recovery is obtained and the DP link is set up with lower voltage swing and pre-emphasis settings than after the initial boot.

I suggest that you try all these 4 patches on top of the drm-intel-nightly and report back if this set provides a fix or not

https://patchwork.freedesktop.org/patch/69394/
https://patchwork.freedesktop.org/patch/69395/
https://patchwork.freedesktop.org/patch/69396/
https://patchwork.freedesktop.org/patch/82206/

Everyone hitting the issue, please attach /sys/kernel/debug/dri/0/i915_vbt (or if that doesn't exist, i915_opregion).

Mika, just an idea... please check the vswing/pre-emph values in VBT. I'm not sure if we parse them in either the driver or intel_bios_reader. Check the VBT spec. Perhaps the VBT values are what we should be using regardless of what the actual link training does.

Simple question for anyone.

What step would you have to do to apply these patch

https://patchwork.freedesktop.org/patch/69394/
https://patchwork.freedesktop.org/patch/69395/
https://patchwork.freedesktop.org/patch/69396/
https://patchwork.freedesktop.org/patch/82206/

There's one thing I still don't understand... the root of the problem was identified in https://bugs.freedesktop.org/show_bug.cgi?id=91393#c25

why hasn't an option to disable the introduced feature been introduced so far?  Or even more, why not reverting completely?  The introduced feature does not work for many of us, making the system unusable, which means that the feature does not work, period.

while on kernel 4.2 that's the only option for me: download the kernel sources in ubuntu and revert the two commits and recompile.

Would reverting the two commits still work on the new Ubuntu which comes with kernel 4.4?

Created attachment 123877 [details] [review]
Revert Fast Link Training

This patch reverts the fast link training feature. However, I have seen that some of the flickering issues are not caused by this feature. Please, give this a go and report back if this patch fixes the screen flickering.

I'm also having the same issue on my XPS 9350 (FHD version)

Attaching /sys/kernel/debug/dri/0/i915_vbt dump as requested.

My machine was running linux 4.6.0-trunk-amd64 from Debian unstable at the moment of the dump and I got flickering after waking up.

It was way worse with older versions of the kernel. So I'm not sure if it's the same bug.

Created attachment 123955 [details]
/sys/kernel/debug/dri/0/i915_vbt dump

(In reply to Mika Kahola from comment #117)
> Created attachment 123877 [details] [review] [review]
> Revert Fast Link Training
> 
> This patch reverts the fast link training feature. However, I have seen that
> some of the flickering issues are not caused by this feature. Please, give
> this a go and report back if this patch fixes the screen flickering.

Mika, I've been following this thread for a while now.

Since kernel 4.3, I always tried and compiled it with a patch that disabled the fast link training feature and it worked. Now, for kernel 4.6, I tried your latest patch and once again my screen is working like a charm. Earlier today, I also tried the latest original kernel, but the flickering was even worse than in previous versions - one can't even pass the gdm login screen!

Please let me know if I can provide and logs or dumps, and their specific files.

Thank you.

(In reply to Evandro Myller from comment #120)
> (In reply to Mika Kahola from comment #117)
> > Created attachment 123877 [details] [review] [review] [review]
> > Revert Fast Link Training
> > 
> > This patch reverts the fast link training feature. However, I have seen that
> > some of the flickering issues are not caused by this feature. Please, give
> > this a go and report back if this patch fixes the screen flickering.
> 
> Mika, I've been following this thread for a while now.
> 
> Since kernel 4.3, I always tried and compiled it with a patch that disabled
> the fast link training feature and it worked. Now, for kernel 4.6, I tried
> your latest patch and once again my screen is working like a charm. Earlier
> today, I also tried the latest original kernel, but the flickering was even
> worse than in previous versions - one can't even pass the gdm login screen!
> 
> Please let me know if I can provide and logs or dumps, and their specific
> files.
> 
> Thank you.

Are you using DP or eDP? Does your panel support PSR? For eDP the fast link training should be ok as you could assume that the cable length and connections are not changing. Anyway, logs and dumps are always welcomed as there are quite a variety of different HW combinations out there.

Created attachment 124480 [details]
VBT dump of affected computer

Regression still present in 4.6.2.  Attached VBT dump as requested.  

When are you guys going to either commit a proper fix or revert the regression on the main line?

Seconding this request for a real fix. This is causing nausea while using my laptop and it would be lovely to have a screen that is reliable (I'm having flickers every minute or so).

http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-git-send-email-mika.kahola@intel.com reverting the fast link training will be merged and backported to stable. We'll stop banging our heads against this. Tested-by's welcome. If flickering remains with that, it's something else.

I had the same problem with my machine (Thinkpad X250, Intel(R) Core(TM) i7-5600U). I'm using the Thinkpad Ultradock and the second screen which is connected via DP flickered occasionally.
This is gone since I'm using the nightly build of last week's Tuesday (kernel 4.7.0-rc2, Commit bb3592f8f98bf02f85da4636f186773f43bc3a65).

commit 91df09d92ad82c8778ca218097bf827f154292ca
Author: Mika Kahola <mika.kahola@intel.com>
Date:   Mon Jun 20 11:10:26 2016 +0300

    drm/i915: Revert DisplayPort fast link training feature

(In reply to Jani Nikula from comment #127)
> commit 91df09d92ad82c8778ca218097bf827f154292ca
> Author: Mika Kahola <mika.kahola@intel.com>
> Date:   Mon Jun 20 11:10:26 2016 +0300
> 
>     drm/i915: Revert DisplayPort fast link training feature

where do we find this fixed kernel in binary form?

(In reply to Lorenzo Bettini from comment #128)
> (In reply to Jani Nikula from comment #127)
> > commit 91df09d92ad82c8778ca218097bf827f154292ca
> > Author: Mika Kahola <mika.kahola@intel.com>
> > Date:   Mon Jun 20 11:10:26 2016 +0300
> > 
> >     drm/i915: Revert DisplayPort fast link training feature
> 
> where do we find this fixed kernel in binary form?

Wait for that to find its way in Linus' upstream, then get backported to stable kernels, then to be picked up by distros, then be rolled out to users...

I built RC5 from git and sadly sadly it doesn't fix the flickering for me. I'm also still getting randomly getting my display shutting down and not recovering until y suspend and wake up the laptop (XPS 13 9350 with FHD panel).
I'll attack another dump of the vbt in case it makes any difference across kernel versions.

Created attachment 124745 [details]
vbt dump after flicker -> panel shutting down -> suspending -> resuming

(In reply to Jani Nikula from comment #129)
> (In reply to Lorenzo Bettini from comment #128)
> > (In reply to Jani Nikula from comment #127)
> > > commit 91df09d92ad82c8778ca218097bf827f154292ca
> > > Author: Mika Kahola <mika.kahola@intel.com>
> > > Date:   Mon Jun 20 11:10:26 2016 +0300
> > > 
> > >     drm/i915: Revert DisplayPort fast link training feature
> > 
> > where do we find this fixed kernel in binary form?
> 
> Wait for that to find its way in Linus' upstream, then get backported to
> stable kernels, then to be picked up by distros, then be rolled out to
> users...

I've tried the ubuntu kernel ppa mainline, and by using this one

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2016-06-21-yakkety/

which I guess it's based on the commit you were mentioning, flickering is gone: I can change the screen resolution and even after screensaver resume there's no flickering.

However, when using desktop effects like "show all windows/expose" (both in unity with compiz and with KDE) there's some flickering...

By the way, while using kernel 4.2 I used to fix the flickering by reverting the commits mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=91393#c25 and recompiling the kernel.

This reverting cannot be done on kernel 4.4 though.  Thus, the reverted commits you're mentioning are not the ones mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=91393#c25 ?

(In reply to Elric from comment #130)
> I built RC5 from git and sadly sadly it doesn't fix the flickering for me.

Then you have a different bug. Please file a new bug.

@Mika Kahola I can reproduce the original problem here with a HD 5500 and the panel of a Dell Chromebook 13 7310.

I was reading https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1522922 and noticed this patch https://patchwork.freedesktop.org/patch/66697/ which unfortunately I did not manage to apply on top of the stable Ubuntu-4.15.0-66.75 kernel as I could not understand how invalidation of the train set works in the more recent tree. The training logic has changed quite a bit.

See also my comment here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1712508/comments/18

All the hints make me think that if I could somehow use the logic which was there in kernel v4.4.0, and which perhaps the mentioned patch would cover, then I could use again this GPU with latest kernels.

I am available for trying patches and submitting the necessary relevant logs as requested; I did not provide any so far because I saw that this bug is closed.