Bug 109959

Reporter, Can you attach the dmesg from boot.
Have you tried to verify the issue with drmtip? (https://cgit.freedesktop.org/drm-tip)
Black screen is shown only when starting X? What did you do immediately to see the normal screen? Asking this to know the impact of this bug. 
Is this issue reproducible every time? Would be good to see the results from drmtip.

As far as i know, that  is dmesg output from boot, i.e. i boot, ssh from another computer and dmesg > file, what else do you think is missing?

> Black screen is shown only when starting X?

Yes (well to be honest i don't know if it's X but it looks like it, i'll attach a video of it)

> What did you do immediately to see the normal screen? 

I don't know what you mean by "normal screen", but you can never see anything again, you have to reboot.

Yes, it is reproducible every time.

No, I have not tried compiling drm-tip, honestly at this point i don't feel like spending my time trying to figure out how to use that unless you tell me that there has been changes regarding the issue i'm reporting.

You can see the boot sequence https://youtu.be/JL0Y3oQ_e9w it will be a black screen forever

if i use the patch i provided, it all looks good and i get the X login display asking for my user/password instead of that black screen

Since I have the same Laptop I can confirm, that I am having this issue too. I spent the last week troubleshooting it and therefor I want to share my current state. First of all it's not only with the X server. This bug appears on the same hardware when you try to load the i915 module with the option 'modeset' set to 1 (enabled). Also it is able to boot into the kernel as long as you keep the option set to 0. (Sadly you're not able to start an X server then) Further investigation (Thanks to the reporter) led me to analyze the workaround: (IMPORTANT FROM NOW ON ITS YET THEORETICAL ONLY, I am investigating further). Since the workaround in drivers/gpu/drm/i915/intel_dp.c forces the first block to never be executed, also nothing else changed, beside the addition of the if statement in line 2033 (I checked everything else). Therefor the bug is caused by the function (line 1882) 'intel_dp_dsc_compute_config', which returns true instead of false.

(In reply to Albert Astals Cid from comment #2)
> As far as i know, that  is dmesg output from boot, i.e. i boot, ssh from
> another computer and dmesg > file, what else do you think is missing?
Logs from first 3 seconds are missing from the attachment. Which platform is this?
 
> I don't know what you mean by "normal screen", but you can never see
> anything again, you have to reboot.

I got the information what I was looking for. Thanks.

Created attachment 143624 [details]
fuller dmesg log

Had to increase the dmesg log size since the ringbuffer was filling up

(In reply to Lakshmi from comment #5)
> (In reply to Albert Astals Cid from comment #2)
> > As far as i know, that  is dmesg output from boot, i.e. i boot, ssh from
> > another computer and dmesg > file, what else do you think is missing?
> Logs from first 3 seconds are missing from the attachment. Which platform is
> this?

Added the fuller dmesg in previous comment. Platform is archlinux (is that what you're asking?)

This enough:
[    0.351237] smpboot: CPU0: Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz (family: 0x6, model: 0x9e, stepping: 0xa)

So looks CFL-H, Lakshmi.

(In reply to Jani Saarinen from comment #8)
> This enough:
> [    0.351237] smpboot: CPU0: Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
> (family: 0x6, model: 0x9e, stepping: 0xa)
> 
> So looks CFL-H, Lakshmi.

This bug also occurs on the Intel(R) Core(TM) i7-8750H

Since it's having the same graphics-chip it should be redundant.

I'm facing the problem since Linux 4.20.13.

Please have a look at his commit:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.20.13&id=218b6d525b036463f3af0e9a1da9d0285ee2bc5b

If it's that bug, can you paste Xorg.0.log?

@Victor please do not hijack my bug report, 4.20.13 works fine here.

[    4.724103] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:85:eDP-1] Link Training failed at link rate = 432000, lane count = 1
[    4.724139] [drm:intel_dp_modeset_retry_work_fn [i915]] [CONNECTOR:85:eDP-1]
...
[    5.863904] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:85:eDP-1] Link Training failed at link rate = 324000, lane count = 1
[    5.863939] [drm:intel_dp_get_link_train_fallback_values [i915]] Retrying Link training for eDP with same parameters
...

So link training no longer works for whatever reason.

(In reply to Ville Syrjala from comment #13)
> [    4.724103] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:85:eDP-1]
> Link Training failed at link rate = 432000, lane count = 1
> [    4.724139] [drm:intel_dp_modeset_retry_work_fn [i915]]
> [CONNECTOR:85:eDP-1]
> ...
> [    5.863904] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:85:eDP-1]
> Link Training failed at link rate = 324000, lane count = 1
> [    5.863939] [drm:intel_dp_get_link_train_fallback_values [i915]] Retrying
> Link training for eDP with same parameters
> ...
> 
> So link training no longer works for whatever reason.

Ah yes it's the fast and narrow vs. wide and slow thing.

[    3.263107] [drm:intel_dp_init_connector [i915]] eDP DPCD: 04 93 a6

So this is a eDP 1.4a sink, which means we'll go for the fast and narrow instead of the old wide and slow apporach.

I helped confirm the kernel patch working for my Dell on arch 5.0.2 but I boot to click not X so I think this isn't an X issue. My DP1-2 worked fine. Just eDP1 was hosed at startup.

(In reply to Joe Lawson from comment #15)
> ... but I boot to click

Was supposed to say boot to cli not X. I use startx after logging in.

Same problem here with the Dell XPS 15 9570.

Black screen when it should get into GNOME Shell Wayland since Linux 5.0.

Created attachment 143729 [details] [review]
parameter-patch

I wrote up this patch to make it easy to switch between forcing the slow and wide to fast modes. If it helps anyone.

I'm also experiencing this issue, on Arch Linux kernel 5.0.3 running on a Dell Precision 5530

BIOS 1.3.0 (07/12/2018)
Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz (family: 0x6, model: 0x9e, stepping: 0xa)
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 630 (Mobile)
01:00.0 3D controller: NVIDIA Corporation GP107GLM [Quadro P1000 Mobile] (rev a1)

I've tried building a kernel package for Arch with Mark's patch applied ( https://github.com/jantman/arch-pkgbuilds/tree/master/linux-precision5530 for PKGBUILD and source, binaries linked from http://archrepo.jasonantman.com/current/index.html ), but when running with that patched kernel and the ``force_edp_wide=1`` parameter set, I see no real difference in behavior from my previous ~35 hours struggling with video on this machine: external displays work fine, eDP is just backlight and black screen.

Would it be possible for someone who's verified this patch to post the details of their kernel parameters and driver versions/config?

(In reply to Jason Antman from comment #19)
> I'm also experiencing this issue, on Arch Linux kernel 5.0.3 running on a
> Dell Precision 5530
> 
> BIOS 1.3.0 (07/12/2018)
> Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz (family: 0x6, model: 0x9e,
> stepping: 0xa)
> 00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 630
> (Mobile)
> 01:00.0 3D controller: NVIDIA Corporation GP107GLM [Quadro P1000 Mobile]
> (rev a1)
> 
> I've tried building a kernel package for Arch with Mark's patch applied (
> https://github.com/jantman/arch-pkgbuilds/tree/master/linux-precision5530
> for PKGBUILD and source, binaries linked from
> http://archrepo.jasonantman.com/current/index.html ), but when running with
> that patched kernel and the ``force_edp_wide=1`` parameter set, I see no
> real difference in behavior from my previous ~35 hours struggling with video
> on this machine: external displays work fine, eDP is just backlight and
> black screen.
> 
> Would it be possible for someone who's verified this patch to post the
> details of their kernel parameters and driver versions/config?

Same for me (Dell XPS 9570): kernel 5.0.3 with Mark's patch has the same issue found in non-patched kernel, while using https://invent.kde.org/snippets/44 patch the system boots fine (I am writing from arch with 5.0.3 kernel patched).

If it can help, my current kernel params are:

add_efi_memmap rw acpi_rev_override=1 nvidia-drm.modeset=1 pcie_port_pm=on acpi_osi="Windows 2009"

Jason, I mistyped in that patch, you need to pass "i915.force_edp_wide=1" to work since that's within the i915 module.

Created attachment 143776 [details]
display edid.log

I did a dump of the edid info of my displays. The edp doesn't work while the DP does.

The patch does work fine. Perhaps this information can help make a better detection routine.

Hi All,
I am working on getting this issue fixed for you all.
So based on the experimental patches and the logs, looks like for this specific eDP panel, it does need max lane count and max link rate for it to pass link training and our optimized fast and narrow approach wont work.
@jani @Ville, do you think the best solution for fixing this would be adding a quirk for this edP panel, looks like its the same panel in all 3 cases.

Manasi

(In reply to Mark Weiman from comment #21)
> Jason, I mistyped in that patch, you need to pass "i915.force_edp_wide=1" to
> work since that's within the i915 module.

Ah, thanks! I haven't recompiled to revert back to your patch and add the proper parameter yet, but I can confirm that Albert's original patch works perfectly for me, so I assume yours would as well (if I'd provided the proper parameters).

I can provide dmesg/edid from my system as well if needed, but it sounds like this is pretty well narrowed-down at this point. Many thanks to all!

Created attachment 143782 [details] [review]
Adds EDID DRM quirk

Created attachment 143783 [details] [review]
i915 use the EDID quirk

Albert, Pascal, Jason, Victor: I have attached the two patches :
1. Add DRM EDID quirk
2. i915 use the EDID quirk

These add the quirk for this specific eDP panel based on the EDID attached and sets the quirk to use wide and slow or the max link rate and max lane count approach which should fix the link training issue.

Could you please apply these on drm-tip in the above order and test them and let me know if this fixes the issue so I can submit those to the M-L?

Regards
Manasi

I have applied the patches on top of linux 5.0.4 ( needed some tweaking, my untrained eye says the patch looks good https://ghostbin.com/paste/2bmk3 ) and it doesn't fix the issue for me.

I've no idea how to use/compile drm-tip 

Is there any howto to explain how to use that on top of a "stable" kernel?

Albert, the patch that you have looks good and if you have the same EDID as the one attached by Joe, this should work.
Do you mind sending me your EDID log and the dmesg with debug level set to 0xe with these patches?

Manasi

Created attachment 143791 [details]
dmesg of drm-tip kernel.

I applied both patches in order ontop of drm-tip an compiled the whole kernel. Sadly I can not confirm that the issue got fixed. I attached the dmesg output. I will attach my EDID.log too

Pascal

Created attachment 143792 [details]
EDID with the patch applied

My Xorg.0.log says

[     6.038] (II) modeset(0): Manufacturer: SHP  Model: 149a  Serial#: 0


So yes it seems it's the same EDID as joe

Created attachment 143793 [details]
dmesg with drm.debug=0xe

Created attachment 143794 [details] [review]
dmesg log with the patch and debug 14

Created attachment 143795 [details]
dmesg log with patch applied and debug 0xe (and log_buffer_size increased)

Sorry for the spam. I forgot to increase the log_buffer_size.


Pascal

Looks like, it didnt use the quirk, let me add some debug prints and give you a debug patch to apply on top of the two so we can see why its not getting the quirk.

Manasi

Created attachment 143796 [details] [review]
Debug patch for the quirk

Could you please try this debug patch on top of the other 2 patches and send me the dmesg log with debug level = 0xe

Manasi

Created attachment 143797 [details]
dmesg log with the extra debug patch and debug 14

Seems only "eDP Debug: eDP 1.4 SHP panle quirk present" is triggered, but not the other two

Created attachment 143801 [details] [review]
Debug Patch v2

Could you please try this v2 of the debug patch on top of the first two quirk patches, this will tell us why its not getting invoked correctly in i915 even though the drm level quirk is getting triggered.

ok, i found the problem, you need to move

if (connector->display_info.force_max_lane_count)
   intel_dp->edp_force_max_lane_count = true;

before
   drm_connector_update_edid_property(connector, edid);

since drm_connector_update_edid_property calls drm_add_display_info that calls drm_reset_display_info and that will reset force_max_lane_count

If you do that it works for me.

Created attachment 143817 [details] [review]
patch that works for me

(In reply to Albert Astals Cid from comment #41)
> Created attachment 143817 [details] [review] [review]
> patch that works for me

Just built kernel 5.0.5 on Archlinux for my Dell XPS 9570 using the patch provided by Albert.
I can confirm no issue at startup, the system boots fine.

I also built 5.0.5 on Archlinux using Albert's patch, but it didn't work. Further investigation revealed the product id for my display is 0x148e. I'm running a Dell XPS 15 2-in-1 9575, with the 1080p display.

I forgot to add that I modified the patch on my end with my product id, and then it worked fine.

(In reply to Albert Astals Cid from comment #41)
> Created attachment 143817 [details] [review] [review]
> patch that works for me

I've applied this patch on top of the Linux Kernel v5.0 tag and it fixes the problems on my Dell Precision 5530.

Unfortunately it does not apply cleanly on v5.1rc3, so I couldn't test the latest pre-release.

Great, so I will swap the position of setting the force_max_lane_count and post the patches to the mailing list with quirks for both panels/both vendor IDs

(In reply to Ralgor from comment #44)
> I forgot to add that I modified the patch on my end with my product id, and
> then it worked fine.

So you just changed the product ID, SHP is still the same right?

Manasi

(In reply to Manasi from comment #47)
> (In reply to Ralgor from comment #44)
> > I forgot to add that I modified the patch on my end with my product id, and
> > then it worked fine.
> 
> So you just changed the product ID, SHP is still the same right?
> 
> Manasi

Yup:

	/* SHP eDP 1.4 panel only works with max lane count */
	{ "SHP", 0x149a, EDID_QUIRK_FORCE_MAX_LANE_COUNT },
        { "SHP", 0x148e, EDID_QUIRK_FORCE_MAX_LANE_COUNT },

Yup, I have added those quirks and patches are on the M-L with you all copied on it:
https://patchwork.freedesktop.org/series/58893/

Hi All,

Another approach for fixing this issue was suggested, can anyone of you please test the patch by itself without any previous quirk patches  to see if it fixes the problem?

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

Manasi

This new patch does not apply on 5.0.6

Sorry, please try the v2 of the patch:

https://patchwork.freedesktop.org/patch/296273/?series=58975&rev=2

Let me know if that fixes the issue.

Manasi

I can already tell that this won't apply either on 5.0.6 because the last hunk (intel_drv.h) is what caused the issue.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/i915/intel_drv.h?h=v5.0.6#n1221

Created attachment 143862 [details] [review]
corrected-patch-5.0.6

Something for use with 5.0.6 (I'm building/testing it currently).

Cool, let me know if it fixes the issue and you can add tested by tag to the patch.

Manasi

I tried a build of 5.0.6 with Mark's 'corrected' patch, but it fails to build on i686 at least:

BUILDSTDERR: drivers/gpu/drm/i915/intel_dp.c: In function 'intel_dp_uses_max_link_params':
BUILDSTDERR: drivers/gpu/drm/i915/intel_dp.c:467:43: error: parameter name omitted
BUILDSTDERR:   467 | static bool intel_dp_uses_max_link_params(struct intel_dp*,
BUILDSTDERR:       |                                           ^~~~~~~~~~~~~~~~
BUILDSTDERR: drivers/gpu/drm/i915/intel_dp.c:471:22: error: 'intel_dp' undeclared (first use in this function)
BUILDSTDERR:   471 |  return link_rate == intel_dp->max_link_rate &&
BUILDSTDERR:       |                      ^~~~~~~~
BUILDSTDERR: drivers/gpu/drm/i915/intel_dp.c:471:22: note: each undeclared identifier is reported only once for each function it appears in
BUILDSTDERR: drivers/gpu/drm/i915/intel_dp.c: At top level:
BUILDSTDERR: drivers/gpu/drm/i915/intel_dp.c:475:13: error: redefinition of 'intel_dp_uses_max_link_params'
BUILDSTDERR:   475 | static bool intel_dp_uses_max_link_params(struct intel_dp *intel_dp,
BUILDSTDERR:       |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BUILDSTDERR: drivers/gpu/drm/i915/intel_dp.c:467:13: note: previous definition of 'intel_dp_uses_max_link_params' was here
BUILDSTDERR:   467 | static bool intel_dp_uses_max_link_params(struct intel_dp*,
BUILDSTDERR:       |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BUILDSTDERR: drivers/gpu/drm/i915/intel_dp.c:467:13: warning: 'intel_dp_uses_max_link_params' defined but not used [-Wunused-function]
BUILDSTDERR: make[4]: *** [scripts/Makefile.build:277: drivers/gpu/drm/i915/intel_dp.o] Error 1
BUILDSTDERR: make[3]: *** [scripts/Makefile.build:492: drivers/gpu/drm/i915] Error 2
BUILDSTDERR: make[3]: *** Waiting for unfinished jobs....

Oh, looking at it carefully, it seems the "corrected" patch mistakenly tries to add intel_dp_uses_max_link_params() twice...

Created attachment 143865 [details] [review]
*really* corrected rediffed 5.0.6 patch

here's a corrected corrected patch =)

Please test

http://patchwork.freedesktop.org/patch/msgid/20190405072439.8922-1-jani.nikula@intel.com

and report back. This is on top of current drm-tip.

(In reply to Jani Nikula from comment #59)
> Please test
> 
> http://patchwork.freedesktop.org/patch/msgid/20190405072439.8922-1-jani.
> nikula@intel.com
> 
> and report back. This is on top of current drm-tip.

Scratch that.

http://patchwork.freedesktop.org/patch/msgid/20190405075220.9815-1-jani.nikula@intel.com

Created attachment 143874 [details] [review]
[v5.0 backport] drm/i915/dp: revert back to max link rate and lane count on eDP

Attached is a backport of the patch to v5.0.

FWIW, a Fedora tester with an affected system reports that this works fine. He tested a scratch build of 5.0.6 with Jani's backport of his own patch, from comment #61.

I've had a few very busy days lately, haven't been able to test, i'll try to find today but may be it takes me until friday

(In reply to Jani Nikula from comment #61)
> Created attachment 143874 [details] [review] [review]
> [v5.0 backport] drm/i915/dp: revert back to max link rate and lane count on
> eDP
> 
> Attached is a backport of the patch to v5.0.

I can confirm this backport works fine for me on 5.0.x

(In reply to Jani Nikula from comment #61)
> Created attachment 143874 [details] [review] [review]
> [v5.0 backport] drm/i915/dp: revert back to max link rate and lane count on
> eDP
> 
> Attached is a backport of the patch to v5.0.

Works for me too (kernel 5.0.7 x86_64 - Arch Linux)

(In reply to Jani Nikula from comment #61)
> Created attachment 143874 [details] [review] [review]
> [v5.0 backport] drm/i915/dp: revert back to max link rate and lane count on
> eDP
> 
> Attached is a backport of the patch to v5.0.

Working correctly here, using Ubuntu 18.04 with Xanmod kernel + this patch

(In reply to Jani Nikula from comment #61)
> Created attachment 143874 [details] [review] [review]
> [v5.0 backport] drm/i915/dp: revert back to max link rate and lane count on
> eDP
> 
> Attached is a backport of the patch to v5.0.

The patch works for me too (Dell Precision 5530).

Patch worked for me on 5.0.7 mainline + Ubuntu patches.  Running Ubuntu 19.04 with no problems now.  qq, will this fix make it's way into 5.0.8 mainline?

This works for me with on a Dell XPS 15 9575 with 1080p display (same as Ralgor) running Arch Linux 5.0.7, but only when patched with this: https://patchwork.freedesktop.org/series/58893/

Created attachment 143967 [details]
journalctl log with drm.debug=14

For some reason the provided patch #143874 didn't work for me, on Fedora kernel 5.0.7 running on a Dell Precision 7530. Full journalctl log provided. This kernel is manually patched, but AFAIK the official kernel was patched already, but it didn't work for me.

It may be another bug, but I doubt it, since it's a very similar case as the rest of the people (Dell laptop, Intel GPU, problem appeared in kernel 5.*)

For now I'm stuck with kernel 4.20.16, which works perfectly.

Doesn't work for me on Dell XPS 15 9570, still black flickering screen. 
Arch linux, kernel 5.0.7.arch1-1.

(In reply to pbazan from comment #71)
> Doesn't work for me on Dell XPS 15 9570, still black flickering screen. 
> Arch linux, kernel 5.0.7.arch1-1.

But are you using the patch provided in attachment 143874 [details] [review] ? 5.0.7 doesn't have this fix in it.

@Jani i'm setting this back to assigned since there's quite a few people that have verified the patch in comment #61 this fixes the problem for us

(In reply to Albert Astals Cid from comment #72)
> (In reply to pbazan from comment #71)
> > Doesn't work for me on Dell XPS 15 9570, still black flickering screen. 
> > Arch linux, kernel 5.0.7.arch1-1.
> 
> But are you using the patch provided in attachment 143874 [details] [review] [review]
> ? 5.0.7 doesn't have this fix in it.

Nope, my understanding was the patch was in 5.0.7 already. I will recheck with the patch applied.

I can confirm that the patch provided in attachment 143874 [details] [review] applied on kernel 5.0.7.arch1-1 works on my Dell XPS 15 9570, while the unpatched kernel does not work.

(In reply to Juan from comment #70)
> Created attachment 143967 [details]
> journalctl log with drm.debug=14
> 
> For some reason the provided patch #143874 didn't work for me, on Fedora
> kernel 5.0.7 running on a Dell Precision 7530. Full journalctl log provided.
> This kernel is manually patched, but AFAIK the official kernel was patched
> already, but it didn't work for me.
> 
> It may be another bug, but I doubt it, since it's a very similar case as the
> rest of the people (Dell laptop, Intel GPU, problem appeared in kernel 5.*)
> 
> For now I'm stuck with kernel 4.20.16, which works perfectly.

I installed now a newer official fedora testing kernel, which I'm sure it has the patch, and it works ok. I probably messed up the kernel build. Sorry for the noise.

So can we close this bug mow? The reverted patch will get backported to stable 5.0.0

Manasi

@Jani, Can we close this issue?

I'm going to close it myself since from what i understand from emails it'll land on both 5.0.x and to be 5.1

Someone shout very strong if i misunderstood :D

Thanks all involved in developing and testing the fix :)

(In reply to Federico Dolce from comment #75)
> I can confirm that the patch provided in attachment 143874 [details] [review]
> [review] applied on kernel 5.0.7.arch1-1 works on my Dell XPS 15 9570, while
> the unpatched kernel does not work.

Works for me too, thank you.

Fixed in Fedora kernel 5.0.7-200.fc29.x86_64.  After upgrading to it, it booted on my Dell 9570 and I'm running it right now!

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

Fixed upstream by

commit 21635d7311734d2d1b177f8a95e2f9386174b76d
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Apr 5 10:52:20 2019 +0300

    drm/i915/dp: revert back to max link rate and lane count on eDP

and the backport is queued for stable v5.0.8.

Thanks everyone for reporting and testing!

Finally one thing that might help us going forward is if all of you affected could attach /sys/kernel/debug/dri/0/i915_vbt please. Does not matter which kernel you're running. Thanks.

Created attachment 143987 [details]
mgarstecki_i915_vbt

Affected here, attached is my /sys/.../i915_vbt

Dell XPS 15 9570, kernel 4.20.13-arch1-1-ARCH.

Created attachment 143988 [details]
/sys/kernel/debug/dri/0/i915_vbt with Kernel 5.0.7-4.g012b5f1-default

Attached /sys/kernel/debug/dri/0/i915_vbt running on Kernel 5.0.7-4.g012b5f1-default from openSUSE Tumbleweed on a Dell Precision 5530 that was affected with Kernel 5.0, now fixed.

Created attachment 143990 [details]
arch linux dell xps 15 9570

Attached

Created attachment 143993 [details]
i915_vbt Dell Precision 7530

/sys/kernel/debug/dri/0/i915_vbt, Fedora, kernel 5.0.7-300.fc30.x86_64, Dell Precision 7530

Here is my dump, done with kernel 5.0.6 (XanMod version), manually compiled with the patch. System is Ubuntu 18.04.2.

Created attachment 144000 [details]
i915 vbt dump

Created attachment 144002 [details]
i915_vbt dump

That's my dump on Dell XPS 9570 running Arch Linux with kernel 5.0.7 compiled with the patch.

5.0.7-arch1-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux

Unfortunately the revert [1] broke some other eDP panels. I tried to come up with a new plan that would handle both types of panels.

I'd appreciate if someone whose machine was fixed by the revert could test the patch in bug 110511 comment 24 so that I don't end up re-breaking things again.

[1] commit 21635d7311734d2d1b177f8a95e2f9386174b76d
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Apr 5 10:52:20 2019 +0300

    drm/i915/dp: revert back to max link rate and lane count on eDP

(In reply to Ville Syrjala from comment #91)
> Unfortunately the revert [1] broke some other eDP panels. I tried to come up
> with a new plan that would handle both types of panels.
> 
> I'd appreciate if someone whose machine was fixed by the revert could test
> the patch in bug 110511 comment 24 so that I don't end up re-breaking things
> again.
> 
> [1] commit 21635d7311734d2d1b177f8a95e2f9386174b76d
> Author: Jani Nikula <jani.nikula@intel.com>
> Date:   Fri Apr 5 10:52:20 2019 +0300
> 
>     drm/i915/dp: revert back to max link rate and lane count on eDP

Maybe I can try it tomorrow, I let you know if I test it.
Which kernel sources I can start from to patch & build? 5.2?

(In reply to Emanuele Panigati from comment #92)
> (In reply to Ville Syrjala from comment #91)
> > Unfortunately the revert [1] broke some other eDP panels. I tried to come up
> > with a new plan that would handle both types of panels.
> > 
> > I'd appreciate if someone whose machine was fixed by the revert could test
> > the patch in bug 110511 comment 24 so that I don't end up re-breaking things
> > again.
> > 
> > [1] commit 21635d7311734d2d1b177f8a95e2f9386174b76d
> > Author: Jani Nikula <jani.nikula@intel.com>
> > Date:   Fri Apr 5 10:52:20 2019 +0300
> > 
> >     drm/i915/dp: revert back to max link rate and lane count on eDP
> 
> Maybe I can try it tomorrow, I let you know if I test it.
> Which kernel sources I can start from to patch & build? 5.2?

Looks like it should apply to 5.2 without much pain. Or you can grab my git branch directly:
git://github.com/vsyrjala/linux.git dp_retry_max_vs_optim

I tested that patch on top of 5.2 and it seems to be working for me