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...
Please attach your xorg log as well.
Created attachment 115570 [details] Xorg.0.log radeon kms
Created attachment 115571 [details] Xorg.0.log fglrx
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?
Created attachment 115573 [details] dmesg with drm.debug=15 Attached dmesg with drm.debug=15, is shows seemingly correct eDP link training
Any news new, or at least some suggestion what code to look into?
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?
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.
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.
(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 ?
Created attachment 115885 [details] [review] possible fix Does this patch help?
(In reply to Alex Deucher from comment #11) > Created attachment 115885 [details] [review] [review] > possible fix > > Does this patch help? Unfortunately no, same symptoms.
bump. Anything else I can try?
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
(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.
Is there are way to enable it in the code provided by 16.40 DKMS package?
(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.
OK, how about pointing me to the bugged eDP workaround code in the latest public DAL code tree?
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
-- 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.
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.