Bug 110675

Summary: Regression: EDP panel flickers with linux 5.1+
Product: DRI Reporter: theli.ua
Component: DRM/IntelAssignee: theli.ua
Status: RESOLVED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: high CC: intel-gfx-bugs
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard: Triaged, ReadyForDev
i915 platform: HSW i915 features: display/eDP
Attachments:
Description Flags
edid-decode /sys/class/drm/card0-eDP-1/edid
none
dmesg 5.1.0 (flicker)
none
dmesg 5.0.15 ( no flicker )
none
5.1.3 with proposed change (always 0x8000)
none
5.1.3 with change to always take min_t path
none
5.1.4 with flickering
none
5.1.4 no flickering none

Description theli.ua 2019-05-14 06:11:00 UTC
Created attachment 144258 [details]
edid-decode /sys/class/drm/card0-eDP-1/edid

Tested with 5.1.0 and 5.1.1, works with 5.0.15 and previous versions

Laptop screen flickers every once in a while since kernel 5.1
this is a Dell laptop - Alienware 15 ANW15-5350SLV, Intel GPU (Well, Intel/Nvidia but intel handles outputs)
Comment 1 theli.ua 2019-05-14 06:19:03 UTC
Correction, last known good kernel version was 5.0.13 (I am yet to test .14 and .15)
and "every once in a while" is about once every 5 second
Comment 2 Lakshmi 2019-05-14 06:22:30 UTC
Can you please attach full dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M?
Comment 3 theli.ua 2019-05-14 06:42:45 UTC
Created attachment 144259 [details]
dmesg 5.1.0 (flicker)
Comment 4 theli.ua 2019-05-14 06:43:25 UTC
Created attachment 144260 [details]
dmesg 5.0.15 ( no flicker )
Comment 5 Ville Syrjala 2019-05-17 16:27:33 UTC
The immediate difference I see is:
[   12.400643] [drm:intel_dump_pipe_config] dp m_n: lanes: 2; gmch_m: 5146655, gmch_n: 8388608, link_m: 285925, link_n: 524288, tu: 64
vs.
[   12.465994] [drm:intel_dump_pipe_config] dp m_n: lanes: 2; gmch_m: 20054, gmch_n: 32768, link_m: 17825, link_n: 32768, tu: 64

Hmm. The relevant commit 53ca2edcf033 ("drm: Change limited M/N quirk to constant N quirk.") is already in both kernels so these really should be identical. I can't see how the quirk could get applied to only dp_m2_n2 but not dp_m_n.

Can you try something silly like:
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7061,7 +7061,7 @@ static void compute_m_n(unsigned int m, unsigned int n,
         * specified fixed N value for asynchronous clock mode,
         * which the devices expect also in synchronous clock mode.
         */
-       if (constant_n)
+       if (1||constant_n)
                *ret_n = 0x8000;
        else
                *ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX);
Comment 6 theli.ua 2019-05-17 18:04:13 UTC
Proposed hack doesn't change the outcome - it still flickers.

However, if I change it to the opposite  - ie to always take min_t path then that seem to fix the flickering.
Comment 7 theli.ua 2019-05-17 18:04:46 UTC
Created attachment 144288 [details]
5.1.3 with proposed change (always 0x8000)
Comment 8 theli.ua 2019-05-17 18:05:12 UTC
Created attachment 144289 [details]
5.1.3 with change to always take min_t path
Comment 9 Ville Syrjala 2019-05-23 14:27:57 UTC
(In reply to theli.ua from comment #6)
> Proposed hack doesn't change the outcome - it still flickers.
> 
> However, if I change it to the opposite  - ie to always take min_t path then
> that seem to fix the flickering.

That is strange.

The new 5.1 log still shows:
[   12.292716] [drm:intel_dump_pipe_config] dp m_n: lanes: 2; gmch_m: 5146655, gmch_n: 8388608, link_m: 285925, link_n: 524288, tu: 64
[   12.292717] [drm:intel_dump_pipe_config] dp m2_n2: lanes: 2; gmch_m: 16044, gmch_n: 32768, link_m: 14261, link_n: 32768, tu: 64

which does not make any sense to me. The N values should all be 0x8000 for both dp_m_n and dp_m2_n2.


Can you try something like this so we can maybe see what's going on?

--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6916,8 +6916,12 @@ static void compute_m_n(unsigned int m, unsigned int n,
        else
                *ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX);
 
+       DRM_DEBUG_KMS("N = %d, constant_n = %d\n", *ret_n, constant_n);
+
        *ret_m = div_u64((u64)m * *ret_n, n);
        intel_reduce_m_n_ratio(ret_m, ret_n);
+
+       DRM_DEBUG_KMS("final N = %d, constant_n = %d\n", *ret_n, constant_n);
 }
 
 void
Comment 10 theli.ua 2019-05-27 17:42:01 UTC
Created attachment 144352 [details]
5.1.4 with flickering
Comment 11 theli.ua 2019-05-27 17:42:24 UTC
Created attachment 144353 [details]
5.1.4 no flickering
Comment 12 theli.ua 2019-05-27 17:44:09 UTC
Without me hacking the kernel N is always 32768
After hacking to take min_t path N varies between 524288 and 8388608
Comment 13 Ville Syrjala 2019-05-31 17:48:30 UTC
(In reply to theli.ua from comment #12)
> Without me hacking the kernel N is always 32768
> After hacking to take min_t path N varies between 524288 and 8388608

So which one flickers? IIRC the original 5.0 vs. 5.1 logs showed that 32768 was fine, but the other value was flickering. But now the latest logs from the 5.1 vs. hacked 5.1 are showing the opposite. I'm 100% confused.
Comment 14 theli.ua 2019-05-31 17:51:11 UTC
The one where the value always stays 32768 flickers
Comment 15 theli.ua 2019-06-05 06:00:30 UTC
And I just doublechecked again.
This is the output of when I change the driver to always take min_t path which makes flickering stop:

dmesg | grep "N ="
[    1.523923] [drm:compute_m_n] N = 8388608, constant_n = 1
[    1.523926] [drm:intel_link_compute_m_n] final N = 8388608, constant_n = 1
[    1.523931] [drm:compute_m_n] N = 524288, constant_n = 1
[    1.523936] [drm:intel_dp_compute_config] final N = 524288, constant_n = 1
[    1.523940] [drm:compute_m_n] N = 8388608, constant_n = 1
[    1.523943] [drm:intel_link_compute_m_n] final N = 8388608, constant_n = 1
[    1.523947] [drm:compute_m_n] N = 524288, constant_n = 1
[    1.523952] [drm:intel_dp_compute_config] final N = 524288, constant_n = 1
[   12.394403] [drm:compute_m_n] N = 8388608, constant_n = 1
[   12.394404] [drm:intel_link_compute_m_n] final N = 8388608, constant_n = 1
[   12.394405] [drm:compute_m_n] N = 524288, constant_n = 1
[   12.394407] [drm:intel_dp_compute_config] final N = 524288, constant_n = 1
[   12.394408] [drm:compute_m_n] N = 8388608, constant_n = 1
[   12.394409] [drm:intel_link_compute_m_n] final N = 8388608, constant_n = 1
[   12.394410] [drm:compute_m_n] N = 524288, constant_n = 1
[   12.394412] [drm:intel_dp_compute_config] final N = 524288, constant_n = 1
[   12.394590] [drm:compute_m_n] N = 8388608, constant_n = 1
[   12.394593] [drm:intel_link_compute_m_n] final N = 8388608, constant_n = 1
[   12.394595] [drm:compute_m_n] N = 524288, constant_n = 1
[   12.394598] [drm:intel_dp_compute_config] final N = 524288, constant_n = 1
[   12.394600] [drm:compute_m_n] N = 8388608, constant_n = 1
[   12.394602] [drm:intel_link_compute_m_n] final N = 8388608, constant_n = 1
[   12.394603] [drm:compute_m_n] N = 524288, constant_n = 1
[   12.394605] [drm:intel_dp_compute_config] final N = 524288, constant_n = 1
Comment 16 Ville Syrjala 2019-06-11 15:24:39 UTC
Please try the patch from bug 110782 comment 18
Comment 17 theli.ua 2019-06-13 05:47:35 UTC
@Ville what kernel version is that patch for? Fails to apply here on 5.1.7
Comment 18 Jani Saarinen 2019-06-13 05:50:31 UTC
I suppose it is for drm-tip: https://cgit.freedesktop.org/drm-tip that today is on Linux version 5.2.0-rc4
Comment 19 theli.ua 2019-06-13 05:54:57 UTC
Either way, I adjusted patch slightly for 5.1.7 so it looks like this https://paste.ee/p/Rpc4E

And it does look like it fixes the issue
Comment 20 Jani Saarinen 2019-06-13 06:29:13 UTC
Can you also add your tested by to https://lists.freedesktop.org/archives/intel-gfx/2019-June/201112.html
Comment 21 Ville Syrjala 2019-06-18 15:33:34 UTC
Fix is in:

commit f0521558a2a89d58a08745e225025d338572e60a
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Jun 12 20:24:23 2019 +0300

    drm/i915: Don't clobber M/N values during fastset check


Thanks for reporting the bug and testing the fix.

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.