From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 73530] Asus U38N: Black screen with Radeon driver in Linux Date: Mon, 11 May 2015 17:59:52 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1855411803==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 851DB6E487 for ; Mon, 11 May 2015 10:59:52 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1855411803== Content-Type: multipart/alternative; boundary="1431367192.Ab2d2.32289"; charset="UTF-8" --1431367192.Ab2d2.32289 Date: Mon, 11 May 2015 17:59:52 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #85 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] > > 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. --1431367192.Ab2d2.32289 Date: Mon, 11 May 2015 17:59:52 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

Comment # 85 on bug 73530 from 
(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.
--1431367192.Ab2d2.32289-- --===============1855411803== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============1855411803==--