https://bugs.freedesktop.org/show_bug.cgi?id=73530
--- Comment #85 from Alex Deucher alexdeucher@gmail.com --- (In reply to N.Leiten from comment #84)
(In reply to Alex Deucher from comment #83)
Created attachment 115699 [details] [review] [review] possible fix
Is the dpcd information always wrong or just sometimes? If it's always wrong, the attached patch might help. If it's only sometimes wrong, we probably need to figure out under what conditions it's wrong.
In my case it was always wrong at point of rate/link calculation, but DPCD itself read right, cause I see in dmesg: [drm:radeon_dp_getdpcd] DPCD: 11 0a 84 01 00 0b 01 01 02 00 00 00 00 00 00
According to this DPCD info we need 0x84 value masked with 0x1f which must return maximum of 4 lanes. But in function radeon_dp_get_dp_lane_number I got dpcd with all zeros instead. So I concluded that somewhere in flow it got NULL'ed.
Ok, the patch shouldn't be necessary then.
I'll check your patch in two-three hours later, little busy at the moment. But is it wise to make additional copies of same data? Maybe I'm a little paranoid, but I always thought that this method is the last variant of solution due to memory consumption. We need to find, where it blows configuration data so in other configurations it'll work as suspected not only in this combination of eDP and LVDS encoder, please correct me if I'm wrong.
There's one copy that gets fetched when the displays are probed (radeon_dp_getdpcd gets called from radeon_connectors.c). Then radeon_dp_set_link_config() which selects the number of names and link rate gets called form radeon_atom_mode_fixup() before the mode is set.