Comment # 85
on bug 73530
from Alex Deucher
(In reply to N.Leiten from comment #84) > (In reply to Alex Deucher from comment #83) > > Created attachment 115699 [details] [review] [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.
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
