<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Asus U38N: Black screen with Radeon driver in Linux" href="https://bugs.freedesktop.org/show_bug.cgi?id=73530#c86">Comment # 86</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Asus U38N: Black screen with Radeon driver in Linux" href="https://bugs.freedesktop.org/show_bug.cgi?id=73530">bug 73530</a> from <a class="email" href="mailto:nickleiten@gmail.com" title="N.Leiten <nickleiten@gmail.com>"> N.Leiten</a> <pre>(In reply to Alex Deucher from <a href="show_bug.cgi?id=73530#c85">comment #85</a>) > (In reply to N.Leiten from <a href="show_bug.cgi?id=73530#c84">comment #84</a>) > > (In reply to Alex Deucher from <a href="show_bug.cgi?id=73530#c83">comment #83</a>) > > > Created <a href="attachment.cgi?id=115699" name="attach_115699" title="possible fix">attachment 115699</a> <a href="attachment.cgi?id=115699&action=edit" title="possible fix">[details]</a> <a href='page.cgi?id=splinter.html&bug=73530&attachment=115699'>[review]</a> [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. Thanks for points of start :) I'll workout this ASAP.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>