Summary: | Regression: EDP panel flickers with linux 5.1+ | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | theli.ua | ||||||||||||||||
Component: | DRM/Intel | Assignee: | 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: |
|
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 Can you please attach full dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M? Created attachment 144259 [details]
dmesg 5.1.0 (flicker)
Created attachment 144260 [details]
dmesg 5.0.15 ( no flicker )
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); 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. Created attachment 144288 [details]
5.1.3 with proposed change (always 0x8000)
Created attachment 144289 [details]
5.1.3 with change to always take min_t path
(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 Created attachment 144352 [details]
5.1.4 with flickering
Created attachment 144353 [details]
5.1.4 no flickering
Without me hacking the kernel N is always 32768 After hacking to take min_t path N varies between 524288 and 8388608 (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. The one where the value always stays 32768 flickers 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 Please try the patch from bug 110782 comment 18 @Ville what kernel version is that patch for? Fails to apply here on 5.1.7 I suppose it is for drm-tip: https://cgit.freedesktop.org/drm-tip that today is on Linux version 5.2.0-rc4 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 Can you also add your tested by to https://lists.freedesktop.org/archives/intel-gfx/2019-June/201112.html 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.
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)