(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.

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.