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.

-- 
You are receiving this mail because:
You are the assignee for the bug.