<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><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#c85">Comment # 85</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 <span class="vcard"><a class="email" href="mailto:alexdeucher@gmail.com" title="Alex Deucher <alexdeucher@gmail.com>"> <span class="fn">Alex Deucher</span></a>
</span></b>
        <pre>(In reply to N.Leiten from <a href="show_bug.cgi?id=73530#c84">comment #84</a>)
<span class="quote">> (In reply to Alex Deucher from <a href="show_bug.cgi?id=73530#c83">comment #83</a>)
> > Created <span class=""><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></span> <a href='page.cgi?id=splinter.html&bug=73530&attachment=115699'>[review]</a> [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.
> </span >

Ok, the patch shouldn't be necessary then.

<span class="quote">> 
> 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.</span >

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.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>