Comment # 84
on bug 73530
from N.Leiten
(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.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
