From: Andres Freund <andres@anarazel.de>
To: "Deucher, Alexander" <Alexander.Deucher@amd.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
David Airlie <airlied@linux.ie>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
Date: Mon, 17 Sep 2012 15:55:42 +0200 [thread overview]
Message-ID: <201209171555.43008.andres@anarazel.de> (raw)
In-Reply-To: <A3397C8B8B789E45844E7EC5DEAD89D02C433367@sausexdag03.amd.com>
On Monday, September 17, 2012 03:16:56 PM Deucher, Alexander wrote:
> > -----Original Message-----
> > From: Andres Freund [mailto:andres@anarazel.de]
> > Sent: Monday, September 17, 2012 7:29 AM
> > To: LKML; Deucher, Alexander; David Airlie;
> > dri-devel@lists.freedesktop.org Subject: radeon: Regression between
> > v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
> >
> > Hi,
> >
> > While debugging another issue I upgraded from v3.6-rc4 to latest git
> > (which exactly is v3.6-rc6). After X started up one of my three monitors
> > blacked out. A look into the kernel log revealed:
> > [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL
>
> What 3 monitors are you using (DVI, HDMI, DP, VGA)? Note that there are
> only 2 PLLs for non-DP monitors, so if you are trying to use more than 2
> non-DP monitors, it's not supported right now and if it worked before, it
> was random luck. If you want to use 3+ monitors, only 2 can be non-DP,
> the rest need to be DP. If you use a DP to DVI/HDMI adapter, it must be
> active (looks like DP to the GPU), passive adapters just pass through
> native DVI/HDMI. That said, I've got a set of patches for 3.7 to allow
> PLL sharing properly for non-DP displays, but it's too invasive for
> -fixes.
2DVI, 1DP via an supposedly active converter. I can try a native DP cable, its
just too short, so I will have to move the monitor to the ground ;)
Can I check its really an active connector?
The patchset you referenced is in alexdeucher/drm-next-3.7-wip if I saw that
correctly? Will test it with a passive connector I have lying arround.
The only somewhat relevant thing in the log seems to be
[ 2.011401] [drm] ring test on 0 succeeded in 3 usecs
[ 2.011897] [drm] ib test on ring 0 succeeded in 0 usecs
[ 2.012596] [drm] Radeon Display Connectors
[ 2.012784] [drm] Connector 0:
[ 2.012972] [drm] DP-1
[ 2.013157] [drm] HPD4
[ 2.013340] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c
0x643c
[ 2.013608] [drm] Encoders:
[ 2.013787] [drm] DFP1: INTERNAL_UNIPHY2
[ 2.013978] [drm] Connector 1:
[ 2.014163] [drm] HDMI-A-1
[ 2.014346] [drm] HPD3
[ 2.014548] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c
0x646c
[ 2.014816] [drm] Encoders:
[ 2.015005] [drm] DFP2: INTERNAL_UNIPHY2
[ 2.015194] [drm] Connector 2:
[ 2.015376] [drm] DVI-D-1
[ 2.015561] [drm] HPD1
[ 2.015745] [drm] DDC: 0x6480 0x6480 0x6484 0x6484 0x6488 0x6488 0x648c
0x648c
[ 2.016015] [drm] Encoders:
[ 2.016203] [drm] DFP3: INTERNAL_UNIPHY1
[ 2.016389] [drm] Connector 3:
[ 2.016574] [drm] DVI-I-1
[ 2.016759] [drm] HPD6
[ 2.016942] [drm] DDC: 0x6470 0x6470 0x6474 0x6474 0x6478 0x6478 0x647c
0x647c
[ 2.017214] [drm] Encoders:
[ 2.017401] [drm] DFP4: INTERNAL_UNIPHY
xrand doesn't seem to have anything relevant:
$ xrandr --verbose|grep -E 'Screen|connected|CRTC'
Screen 0: minimum 320 x 200, current 4960 x 1920, maximum 16384 x 16384
DVI-1 connected 2560x1600+1200+0 (0x59) normal (normal left inverted right x
axis y axis) 641mm x 401mm
CRTC: 0
CRTCs: 1 2 0 3 4 5
DisplayPort-0 connected 1200x1920+0+0 (0x60) left (normal left inverted right x
axis y axis) 518mm x 324mm
CRTC: 1
CRTCs: 1 2 0 3 4 5
HDMI-0 disconnected (normal left inverted right x axis y axis)
CRTCs: 1 2 0 3 4 5
DVI-0 connected 1200x1920+3760+0 (0x60) left (normal left inverted right x axis
y axis) 518mm x 324mm
CRTC: 2
CRTCs: 1 2 0 3 4 5
Greetings,
Andres
next prev parent reply other threads:[~2012-09-17 13:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-17 11:29 radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL Andres Freund
2012-09-17 13:16 ` Deucher, Alexander
2012-09-17 13:55 ` Andres Freund [this message]
2012-09-17 14:24 ` Deucher, Alexander
2012-09-17 17:15 ` Andres Freund
2012-09-17 19:30 ` Deucher, Alexander
2012-09-17 19:30 ` Deucher, Alexander
2012-09-26 13:00 ` Dan Carpenter
2012-09-26 13:20 ` Deucher, Alexander
2012-09-26 13:41 ` Andres Freund
2012-09-26 13:42 ` Deucher, Alexander
2012-09-27 6:46 ` Andres Freund
2012-09-27 13:14 ` Alex Deucher
2012-09-27 13:14 ` Alex Deucher
2012-09-27 13:23 ` Andres Freund
2012-09-27 14:54 ` Alex Deucher
2012-09-27 16:19 ` Alex Deucher
2012-10-02 17:04 ` Andres Freund
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201209171555.43008.andres@anarazel.de \
--to=andres@anarazel.de \
--cc=Alexander.Deucher@amd.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.