Bug 110511 - i915 flickering in new XPS13 9380 (2019)
Summary: i915 flickering in new XPS13 9380 (2019)
Status: NEEDINFO
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: high critical
Assignee: Ville Syrjala
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-25 10:24 UTC by Paulo J. Matos
Modified: 2019-08-13 07:31 UTC (History)
4 users (show)

See Also:
i915 platform: CFL
i915 features: display/Other


Attachments
dmesg from boot (145.72 KB, text/plain)
2019-04-25 10:24 UTC, Paulo J. Matos
no flags Details
[PATCH] drm/i915: Dump the full ESI register block on short pulse (1.32 KB, patch)
2019-05-17 15:10 UTC, Ville Syrjala
no flags Details | Splinter Review
Timo rc5+ kernel dmesg (241.52 KB, text/x-log)
2019-05-22 13:02 UTC, Paulo J. Matos
no flags Details
rc5+ kernel with enable_psr=0 (249.43 KB, text/x-log)
2019-05-22 16:19 UTC, Paulo J. Matos
no flags Details
[PATCH] hack: Disable 5.4ghz link rate for skl (855 bytes, patch)
2019-05-22 18:11 UTC, Ville Syrjala
no flags Details | Splinter Review
[PATCH] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure (6.31 KB, patch)
2019-07-11 16:15 UTC, Ville Syrjala
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Paulo J. Matos 2019-04-25 10:24:02 UTC
Created attachment 144092 [details]
dmesg from boot

This was previously reported here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1826125

Brand new XPS 13 9380 arrived a couple of days ago from Dell with Ubuntu 18.04 preinstalled.

Flickering started immediatelly post boot and it was constant.
I updated BIOS from 1.1.1 to 1.2.1, tried i915.fastboot and i915.enable_rc6 combinations to no avail. 

Updated to Ubuntu 19.04 and kernel-5 to no avail. However flickering changed from constant to only if there's a screen refresh.

Videos pre kernel 5:
https://photos.app.goo.gl/1PkL2HrjMBP41aML9
https://photos.app.goo.gl/CMzmMwrCPH5wh8aw6

Videos post kernel 5:
https://photos.app.goo.gl/tpmTGWVJXpChoERz6

I attach dmesg from boot.
Comment 1 Timo Aaltonen 2019-04-25 15:14:17 UTC
and happens with current nightly too
Comment 2 Lakshmi 2019-04-29 05:47:06 UTC
Stan, any help here? I see hotplug events in dmesg.
Comment 3 Timo Aaltonen 2019-05-16 06:09:13 UTC
Ping? With 5.0 and up PSR seems to be messing with the results, but disabling it doesn't fix the original issue.
Comment 4 Paulo J. Matos 2019-05-16 06:12:33 UTC
If I can help at all sorting this one out let me know. logs, ssh access to the machine, you name it.
Comment 5 Ville Syrjala 2019-05-17 15:10:20 UTC
Created attachment 144287 [details] [review]
[PATCH] drm/i915: Dump the full ESI register block on short pulse

This patch might help us figure out what the sink is trying to tell us.
Comment 6 Timo Aaltonen 2019-05-17 18:13:29 UTC
thanks Ville, here's a kernel deb based on drm-intel-next-fixes-2019-05-15 plus this patch

http://aaltoset.kapsi.fi/xps13-flicker/

Paulo, please install, boot with drm.debug=14 and attach dmesg
Comment 7 Paulo J. Matos 2019-05-22 13:02:05 UTC
Created attachment 144318 [details]
Timo rc5+ kernel dmesg
Comment 8 Paulo J. Matos 2019-05-22 13:03:03 UTC
Timo, I have attached the dmesg with rc5+ kernel you asked me to test.
Comment 9 Ville Syrjala 2019-05-22 15:51:07 UTC
[    4.550517] [drm:intel_dp_hpd_pulse [i915]] ESI: 41 00 00 00 00 00 00 00 00 00 00 00 81 01

According to that the sink thinks everything is fine, so no idea why generates short hpds.

Could be some kind of PSR fail. Please try passing i915.enable_psr=0 to the kernel cmdline.
Comment 10 Paulo J. Matos 2019-05-22 16:18:47 UTC
(In reply to Ville Syrjala from comment #9)
> [    4.550517] [drm:intel_dp_hpd_pulse [i915]] ESI: 41 00 00 00 00 00 00 00
> 00 00 00 00 81 01
> 
> According to that the sink thinks everything is fine, so no idea why
> generates short hpds.
> 
> Could be some kind of PSR fail. Please try passing i915.enable_psr=0 to the
> kernel cmdline.

enable_psr=0 does not help. Posting dmesg with enable_psr=0.
Comment 11 Paulo J. Matos 2019-05-22 16:19:30 UTC
Created attachment 144319 [details]
rc5+ kernel with enable_psr=0
Comment 12 Paulo J. Matos 2019-05-22 16:23:01 UTC
In https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1826125/comments/53 it is mentioned that the same laptop with PCLinuxOS with 5.0.2 doesn't flicker. Is it worth it getting some data from there perhaps?
Comment 13 Ville Syrjala 2019-05-22 18:10:15 UTC
(In reply to Paulo J. Matos from comment #11)
> Created attachment 144319 [details]
> rc5+ kernel with enable_psr=0

The log was cut off so couldn't see that PSR was in fact disabled. You can fix that by passing eg. log_buf_len=2M to the kernel cmdline.

Anyways, after a second glance at the logs I see the sink does sometimes indicate that the receiver port was not synchronized. Not sure why the failure manifests at that level with the link otherwise being reported as stable. Looks like we could try to reduce the link rate a bit and still have enough bandwidth for the 4k@60 mode. I'll attach something to that effect.
Comment 14 Ville Syrjala 2019-05-22 18:11:53 UTC
Created attachment 144325 [details] [review]
[PATCH] hack: Disable 5.4ghz link rate for skl

This should drop the link rate to 4.32ghz, which is the lowest we can go with this panel. Please test.
Comment 15 Ville Syrjala 2019-05-22 18:18:22 UTC
Hmm, yes 4.32 is what the BIOS uses, so this might even help:
[    1.391106] [drm:intel_dump_pipe_config [i915]] port clock: 432000, pipe src size: 3840x2160, pixel rate 533299

Hmm. That probably means this is a victim of commit f11cb1c19ad0 ("drm/i915/dp: revert back to max link rate and lane count on eDP"), which I think would have picked the lower link rate for us.

Yes, eDP revision seems to be 1.4a:
[    1.385017] [drm:intel_dp_init_connector [i915]] eDP DPCD: 04 92 a5
so I believe that is indeed what would have happened.
Comment 16 Timo Aaltonen 2019-05-23 19:53:51 UTC
new kernel build with the hack in

http://aaltoset.kapsi.fi/xps13-flicker/
Comment 17 Paulo J. Matos 2019-05-25 16:40:26 UTC
I can confirm that with Timo's kernel, with Ville's patch it all works smoothly.
Great job guys! Thanks so much for the support. I will keep using this kernel until upstream is fixed. Can you please update this bug once a proper fix hits upstream?
Comment 18 Ville Syrjala 2019-05-27 12:01:22 UTC
Can we get a test with just 'git revert f11cb1c19ad0' ?
Comment 19 Timo Aaltonen 2019-05-28 06:11:01 UTC
kernel -10 with the revert availabe behind the same url

but reverting it would reopen 109959
Comment 20 Timo Aaltonen 2019-06-06 21:15:05 UTC
Paulo, please test kernel build -10
Comment 21 Paulo J. Matos 2019-06-07 06:59:58 UTC
Apologies, I dropped the ball on this one. I will do that today.
Comment 22 Paulo J. Matos 2019-06-08 21:25:09 UTC
I can confirm that the kernel with the reverted commit works. Apologies for the delay.
Comment 23 josh 2019-06-25 07:25:07 UTC
Hi all,

I have been following this bug report for a while - I just wanted to check in on status. Will the fix be rolled out now that Paulo has confirmed the working kernel version?
Comment 24 Ville Syrjala 2019-07-11 16:15:41 UTC
Created attachment 144765 [details] [review]
[PATCH] drm/i915: Try to use fast+narrow link on eDP again and fall  back to the old max strategy on failure

Here's an attempt at fixing this without horribly breaking a bunch of other eDP panels. Would appreciate if people can test this.

Also available here in git form:
git://github.com/vsyrjala/linux.git dp_retry_max_vs_optim
Comment 25 Kai-Heng Feng 2019-07-17 05:35:21 UTC
Timo isn't around, please test this kernel:
https://people.canonical.com/~khfeng/bfo110511/
Comment 26 Paulo J. Matos 2019-07-17 09:00:23 UTC
I will take a look a this later. Apologies but I am on and off summer holidays these days.
Comment 27 Kai-Heng Feng 2019-08-13 07:31:21 UTC
According to 
https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1827790/comments/19

This issue is fixed by "dp_retry_max_vs_optim" branch.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.