|Summary:||Lenovo ThinkPad E455 (Kaveri A10-7300): Blank built-in screen with radeon kms driver|
|Product:||DRI||Reporter:||Samir Ibradžić <sibradzic>|
|Component:||DRM/Radeon||Assignee:||Default DRI bug account <dri-devel>|
|Status:||RESOLVED MOVED||QA Contact:|
|Priority:||highest||CC:||brookskd, nickleiten, niels_ole|
|i915 platform:||i915 features:|
Description Samir Ibradžić 2015-05-05 17:37:25 UTC
Created attachment 115550 [details] dmesg 4.1 rc1 As soon as the radeon kms switches in from efifb, the screen goes blank for the moment (no backlight), and then the backlight switches in, but the screen remains black. External HDMI output works just fine. No X is involved, I can't even see the kms console @ eDP. I can even control the backlight on the eDP display, but all i get is the various shades of black. Fglrx works fine, although it flickers wildly before the picture gets stable. I've tried numerous things, like forcing EDID that was grabbed from fglrx, disabling audio, applying all the DP training / backlight disabling patches as in https://bugs.freedesktop.org/show_bug.cgi?id=73530, all to no avail. Currently on linux 4.1rc1, tried 3.13, 3.16 & 3.19 as well, same issue. Please help! I bought this laptop cause I prefer AMD, and was expecting Lenovo to work great with Linux, but so far its broken. Ready to try some patches...
Comment 1 Alex Deucher 2015-05-05 18:49:35 UTC
Please attach your xorg log as well.
Comment 2 Samir Ibradžić 2015-05-06 04:19:59 UTC
Created attachment 115570 [details] Xorg.0.log radeon kms
Comment 3 Samir Ibradžić 2015-05-06 04:21:04 UTC
Created attachment 115571 [details] Xorg.0.log fglrx
Comment 4 Samir Ibradžić 2015-05-06 04:23:01 UTC
Attached xorg logs, both for radeon kms & fglrx. Anyone knows if fglrx has some kind of debug log where DP link training bits may be visible?
Comment 5 Samir Ibradžić 2015-05-06 04:48:12 UTC
Created attachment 115573 [details] dmesg with drm.debug=15 Attached dmesg with drm.debug=15, is shows seemingly correct eDP link training
Comment 6 Samir Ibradžić 2015-05-08 13:08:40 UTC
Any news new, or at least some suggestion what code to look into?
Comment 7 Nicolas Werner 2015-05-11 14:18:00 UTC
N.Leiten seems to have found something, while looking into https://bugs.freedesktop.org/show_bug.cgi?id=73530 . As your problem seems to be rather similar, once there is a patch, the fix will hopefully also apply to you. Also there is some more information about what he found, maybe this can help you?
Comment 8 N.Leiten 2015-05-13 07:01:58 UTC
Created attachment 115731 [details] FHD Panel Datasheet. Due this datasheet the panel looks the same as for DP configuration comparing whith N133HSE-EA1 (asus u38n) panel. So it needs 2 lanes to init video stream. As for your dmesg, I see problem in dp_aux_ch and training procedure (the voltage and emphasis is 0 which is not right at this point). Need to debug further when I publish my patch and if it not help. One more thing, do you have FullHD (1920x1080) panel or WHD (1366x768) one. Because on Lenovo site I see Thinkpad e455 base model with WHD. The last one need only 1 DisplayPort lane to work.
Comment 9 Samir Ibradžić 2015-05-13 15:22:17 UTC
Created attachment 115742 [details] HB140FH1-401 datasheet Finally got my hands on some p-coins (damn the neo-capitalist China!) and fetched the datasheet for my panel (or at least what i think i have inside my E455 according to EDID, but it seems right as several other Lenovo laptops comes with the same thing included). The timings looks the same as U38N, it is definitely 2 2.7Gbps lanes, but I can't claim i understand much besides that inside the datasheet. Yes, the panel is is full HD 1920x1080, here in Lenovo Japan it is available as an +$20 option, which was the main reason I bought this particular machine (besides the fact its AMD APU of course). I can help debugging any patches or code hacks, so if you have any ideas, onegaishimasu.
Comment 10 Samir Ibradžić 2015-05-16 15:53:35 UTC
(In reply to N.Leiten from comment #8) > Created attachment 115731 [details] > FHD Panel Datasheet. > > Due this datasheet the panel looks the same as for DP configuration > comparing whith N133HSE-EA1 (asus u38n) panel. So it needs 2 lanes to init > video stream. > > As for your dmesg, I see problem in dp_aux_ch and training procedure (the > voltage and emphasis is 0 which is not right at this point). Need to debug > further when I publish my patch and if it not help. > > One more thing, do you have FullHD (1920x1080) panel or WHD (1366x768) one. > Because on Lenovo site I see Thinkpad e455 base model with WHD. The last one > need only 1 DisplayPort lane to work. Are you saying these may be an issue: [drm:radeon_dp_aux_transfer_native] dp_aux_ch flags not zero: 00000201 [drm:drm_dp_i2c_do_msg] transaction failed: -5 ?
Comment 11 Alex Deucher 2015-05-18 21:54:54 UTC
Created attachment 115885 [details] [review] possible fix Does this patch help?
Comment 12 Samir Ibradžić 2015-05-19 01:39:25 UTC
(In reply to Alex Deucher from comment #11) > Created attachment 115885 [details] [review] [review] > possible fix > > Does this patch help? Unfortunately no, same symptoms.
Comment 13 Samir Ibradžić 2015-05-25 13:12:39 UTC
bump. Anything else I can try?
Comment 14 Samir Ibradžić 2016-11-17 17:57:24 UTC
A year and a half later, BUMP again - This bug is still happening on upstream kernels, just tried against 4.9 rc5 - It happens on latest amdgpu, with CIK support compiled - It even happens with amdgpu-pro DKMS 16.40.5 @ Ubuntu 16.04 @ 4.4.0-47.68 which supposedly enables DAL (it doesn't want to compile on newer kernels) The same implications as before, eDP is black, backlight control works, external HDMI works. It only works with fglrx, just checked with 15.20.2 (Feb 27 2015 build) @ Ubuntu 15.04 @ 4.0.0-040000-generic (ubuntu ppa kernel), display inits fine, X works, but Gnome just dies on it, so I'm forced to use desktop that I can't stand... Whay would fglrx know how to enable eDP, when all other fail? Is there some dark display initialization voodoo magic in there that is not in amdgpu-pro DAL? Some sort of workaround in the code dedicated to handle some buggy eDP link training or i2c link issues that are known for some LCD displays? Please Help
Comment 15 Alex Deucher 2016-11-17 18:33:05 UTC
(In reply to Samir Ibradžić from comment #14) > > Whay would fglrx know how to enable eDP, when all other fail? Is there some > dark display initialization voodoo magic in there that is not in amdgpu-pro > DAL? Some sort of workaround in the code dedicated to handle some buggy eDP > link training or i2c link issues that are known for some LCD displays? DAL is not currently enabled for Kaveri.
Comment 16 Samir Ibradžić 2016-11-17 18:41:26 UTC
Is there are way to enable it in the code provided by 16.40 DKMS package?
Comment 17 Alex Deucher 2016-11-17 18:43:10 UTC
(In reply to Samir Ibradžić from comment #16) > Is there are way to enable it in the code provided by 16.40 DKMS package? Not at the moment.
Comment 18 Samir Ibradžić 2016-11-17 18:47:42 UTC
OK, how about pointing me to the bugged eDP workaround code in the latest public DAL code tree?
Comment 19 Alex Deucher 2016-11-17 19:13:55 UTC
Certain panels can be really picky about sequencing or delays in the link training. I suspect there are mainly just slight differences in the programming sequences that some panels just don't like. The core link training code for DAL is here: https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/dal/dc/core/dc_link_dp.c?h=amd-staging-4.7
Comment 20 Martin Peres 2019-11-19 09:04:48 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/611.