radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Andres Freund]

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

During that first start I tried to correct that using xrand, which failed. 
After restarting X (gdm) once more the monitor was still blank, the error was 
still logged, but could be enabled by using xrandr. A bit strange.

A quick look into git revealed:

$ git log --pretty=short v3.6-rc4.. drivers/gpu/drm/radeon/
commit f492c171a38d77fc13a8998a0721f2da50835224
Author: Christian König <deathsimple@vodafone.de>

    drm/radeon: make 64bit fences more robust v3

commit 985f61f7ee647ad570c05eab0b74915da2ac8e19
Author: Alex Deucher <alexander.deucher@amd.com>

    drm/radeon: rework pll selection (v3)

The latter seems to be a probably cause. Anything I can do to diagnose the 
issue?

$ xrandr|grep -E 'connected|Screen'
Screen 0: minimum 320 x 200, current 4960 x 1920, maximum 16384 x 16384
DVI-1 connected 2560x1600+1200+0 (normal left inverted right x axis y axis) 
641mm x 401mm
DisplayPort-0 connected 1200x1920+0+0 left (normal left inverted right x axis y 
axis) 518mm x 324mm
HDMI-0 disconnected (normal left inverted right x axis y axis)
DVI-0 connected 1200x1920+3760+0 left (normal left inverted right x axis y 
axis) 518mm x 324mm

# lspci -v -s 08:00.0
08:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Barts 
XT [Radeon HD 6800 Series] (prog-if 00 [VGA controller])
	Subsystem: PC Partner Limited Device 174b
	Flags: bus master, fast devsel, latency 0, IRQ 76
	Memory at d0000000 (64-bit, prefetchable) [size=256M]
	Memory at fbec0000 (64-bit, non-prefetchable) [size=128K]
	I/O ports at e000 [size=256]
	Expansion ROM at fbea0000 [disabled] [size=128K]
	Capabilities: [50] Power Management version 3
	Capabilities: [58] Express Legacy Endpoint, MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [150] Advanced Error Reporting
	Kernel driver in use: radeon

Greetings,

Andres

RE: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Deucher, Alexander]

> -----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.

Alex

Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Andres Freund]

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

RE: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Deucher, Alexander]

[-- Attachment #1: Type: text/plain, Size: 2255 bytes --]

> -----Original Message-----
> From: Andres Freund [mailto:andres@anarazel.de]
> Sent: Monday, September 17, 2012 9:56 AM
> To: Deucher, Alexander
> Cc: LKML; David Airlie; dri-devel@lists.freedesktop.org
> Subject: Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to
> allocate a PPLL
> 
> 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?

Try the attached debugging patch.  It will tell us what PPLLs are getting allocated and what type of sink we detect on the DP port (DP or non-DP)

> 
> 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.
> 

Yes.  Note that PLLs can only be shared for non-DP monitors if the clocks are the same.

Alex


[-- Attachment #2: debug_dp.diff --]
[-- Type: application/octet-stream, Size: 1228 bytes --]

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index e721e30..d287d18 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1735,6 +1735,8 @@ static void atombios_crtc_prepare(struct drm_crtc *crtc)
 	radeon_crtc->in_mode_set = true;
 	/* pick pll */
 	radeon_crtc->pll_id = radeon_atom_pick_pll(crtc);
+	DRM_INFO("crtc %d using pll 0x%x\n",
+		 radeon_crtc->crtc_id, radeon_crtc->pll_id);
 
 	/* disable crtc pair power gating before programming */
 	if (ASIC_IS_DCE6(rdev))
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c
index 895e628..41fe2e5 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1400,6 +1400,7 @@ radeon_dp_detect(struct drm_connector *connector, bool force)
 		}
 	} else {
 		radeon_dig_connector->dp_sink_type = radeon_dp_getsinktype(radeon_connector);
+		DRM_INFO("DP sink type 0x%x\n", radeon_dig_connector->dp_sink_type);
 		if (radeon_hpd_sense(rdev, radeon_connector->hpd.hpd)) {
 			ret = connector_status_connected;
 			if (radeon_dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_DISPLAYPORT)

Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Andres Freund]

Hi,

On Monday, September 17, 2012 04:24:08 PM Deucher, Alexander wrote:
> > On Monday, September 17, 2012 03:16:56 PM Deucher, Alexander wrote:
> > > > 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?
> 
> Try the attached debugging patch.  It will tell us what PPLLs are getting
> allocated and what type of sink we detect on the DP port (DP or non-DP)
[    1.844382] [drm] Initialized drm 1.1.0 20060810
[    1.867560] [drm] radeon defaulting to kernel modesetting.
[    1.890474] [drm] radeon kernel modesetting enabled.
[    1.913006] fb: conflicting fb hw usage radeondrmfb vs VGA16 VGA - removing 
generic driver
[    1.981793] [drm] initializing kernel modesetting (BARTS 0x1002:0x6738 
0x174B:0x174B).
[    1.982323] [drm] register mmio base: 0xFBEC0000
[    1.982522] [drm] register mmio size: 131072
[    1.983880] [drm] Detected VRAM RAM=1024M, BAR=256M
[    1.984072] [drm] RAM width 256bits DDR
[    1.985141] [drm] radeon: 1024M of VRAM memory ready
[    1.985345] [drm] radeon: 512M of GTT memory ready.
[    1.985575] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[    1.985779] [drm] Driver supports precise vblank timestamp query.
[    1.986252] [drm] radeon: irq initialized.
[    1.986454] [drm] GART: num cpu pages 131072, num gpu pages 131072
[    1.987226] [drm] probing gen 2 caps for device 8086:340a = 2/0
[    1.987426] [drm] enabling PCIE gen 2 link speeds, disable with 
radeon.pcie_gen2=0
[    1.987930] [drm] Loading BARTS Microcode
[    1.990807] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
[    2.008503] [drm] ring test on 0 succeeded in 3 usecs
[    2.009029] [drm] ib test on ring 0 succeeded in 0 usecs
[    2.009728] [drm] Radeon Display Connectors
[    2.009914] [drm] Connector 0:
[    2.010103] [drm]   DP-1
[    2.010283] [drm]   HPD4
[    2.010464] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 
0x643c
[    2.010734] [drm]   Encoders:
[    2.010921] [drm]     DFP1: INTERNAL_UNIPHY2
[    2.011112] [drm] Connector 1:
[    2.011295] [drm]   HDMI-A-1
[    2.011478] [drm]   HPD3
[    2.011662] [drm]   DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 
0x646c
[    2.011932] [drm]   Encoders:
[    2.012119] [drm]     DFP2: INTERNAL_UNIPHY2
[    2.012324] [drm] Connector 2:
[    2.012512] [drm]   DVI-D-1
[    2.012695] [drm]   HPD1
[    2.012881] [drm]   DDC: 0x6480 0x6480 0x6484 0x6484 0x6488 0x6488 0x648c 
0x648c
[    2.013152] [drm]   Encoders:
[    2.013340] [drm]     DFP3: INTERNAL_UNIPHY1
[    2.013528] [drm] Connector 3:
[    2.013712] [drm]   DVI-I-1
[    2.013898] [drm]   HPD6
[    2.014082] [drm]   DDC: 0x6470 0x6470 0x6474 0x6474 0x6478 0x6478 0x647c 
0x647c
[    2.014352] [drm]   Encoders:
[    2.014538] [drm]     DFP4: INTERNAL_UNIPHY
[    2.014724] [drm]     CRT1: INTERNAL_KLDSCP_DAC1
[    2.015014] [drm] Internal thermal controller with fan control
[    2.016370] [drm] radeon: power management initialized
[    2.022137] [drm] DP sink type 0x13
[    2.133666] [drm] fb mappable at 0xD0142000
[    2.133793] [drm] vram apper at 0xD0000000
[    2.133919] [drm] size 16384000
[    2.134044] [drm] fb depth is 24
[    2.134170] [drm]    pitch is 10240
[    2.134358] fbcon: radeondrmfb (fb0) is primary device
[    2.134901] [drm] crtc 0 using pll 0x2
[    2.362257] [drm] crtc 1 using pll 0x1
[    2.386709] [drm] crtc 2 using pll 0x0
[    2.472275] fb0: radeondrmfb frame buffer device
[    2.472300] drm: registered panic notifier
[    2.472325] [drm] Initialized radeon 2.22.0 20080528 for 0000:08:00.0 on 
minor 0
[   60.056358] [drm] DP sink type 0x13
[   60.205905] [drm] DP sink type 0x13
[   60.679305] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL
[   60.679310] [drm] crtc 0 using pll 0xff
[   60.789183] [drm] crtc 1 using pll 0x2
[   60.819594] [drm] crtc 2 using pll 0x1
[   61.926401] [drm] DP sink type 0x13
[   73.022055] [drm] DP sink type 0x13
[   73.567827] [drm] DP sink type 0x13
[ 2654.041357] [drm] crtc 0 using pll 0x2
[ 2654.146105] [drm] crtc 1 using pll 0x0
[ 2654.193906] [drm] crtc 2 using pll 0x1
[ 2699.743567] [drm] DP sink type 0x13
[ 2699.892998] [drm] DP sink type 0x13
[ 2699.982947] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL
[ 2699.982950] [drm] crtc 0 using pll 0xff
[ 2700.104885] [drm] crtc 1 using pll 0x2
[ 2700.150563] [drm] crtc 2 using pll 0x1
[ 2700.289148] [drm] DP sink type 0x13
[ 2700.785181] [drm] DP sink type 0x13
[ 2730.400834] [drm] crtc 0 using pll 0x2
[ 2730.448034] [drm] crtc 1 using pll 0x0
[ 2730.490630] [drm] crtc 2 using pll 0x1
[ 2737.092937] [drm] DP sink type 0x13
[ 2737.242505] [drm] DP sink type 0x13
[ 2737.331883] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL
[ 2737.331886] [drm] crtc 0 using pll 0xff
[ 2737.453714] [drm] crtc 1 using pll 0x2
[ 2737.509907] [drm] crtc 2 using pll 0x1
[ 2737.645287] [drm] DP sink type 0x13
[ 2738.207736] [drm] DP sink type 0x13
[ 2763.766354] [drm] DP sink type 0x13
[ 2763.882633] [drm] DP sink type 0x13
[ 2764.118995] [drm] crtc 0 using pll 0x2
[ 2764.223623] [drm] crtc 1 using pll 0x0
[ 2764.273047] [drm] crtc 2 using pll 0x1
[ 2767.566733] [drm] DP sink type 0x13

> > 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.
> 
> Yes.  Note that PLLs can only be shared for non-DP monitors if the clocks
> are the same.
That should be fine, two of the three monitors are the same.

Greetings,

Andres

RE: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Deucher, Alexander]

> -----Original Message-----
> From: Andres Freund [mailto:andres@anarazel.de]
> Sent: Monday, September 17, 2012 1:16 PM
> To: Deucher, Alexander
> Cc: LKML; David Airlie; dri-devel@lists.freedesktop.org
> Subject: Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to
> allocate a PPLL
> 
> Hi,
> 
> On Monday, September 17, 2012 04:24:08 PM Deucher, Alexander wrote:
> > > On Monday, September 17, 2012 03:16:56 PM Deucher, Alexander wrote:
> > > > > 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?
> >
> > Try the attached debugging patch.  It will tell us what PPLLs are getting
> > allocated and what type of sink we detect on the DP port (DP or non-DP)
> [    1.844382] [drm] Initialized drm 1.1.0 20060810
> [    1.867560] [drm] radeon defaulting to kernel modesetting.
> [    1.890474] [drm] radeon kernel modesetting enabled.
> [    1.913006] fb: conflicting fb hw usage radeondrmfb vs VGA16 VGA -
> removing
> generic driver
> [    1.981793] [drm] initializing kernel modesetting (BARTS 0x1002:0x6738
> 0x174B:0x174B).
> [    1.982323] [drm] register mmio base: 0xFBEC0000
> [    1.982522] [drm] register mmio size: 131072
> [    1.983880] [drm] Detected VRAM RAM=1024M, BAR=256M
> [    1.984072] [drm] RAM width 256bits DDR
> [    1.985141] [drm] radeon: 1024M of VRAM memory ready
> [    1.985345] [drm] radeon: 512M of GTT memory ready.
> [    1.985575] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [    1.985779] [drm] Driver supports precise vblank timestamp query.
> [    1.986252] [drm] radeon: irq initialized.
> [    1.986454] [drm] GART: num cpu pages 131072, num gpu pages 131072
> [    1.987226] [drm] probing gen 2 caps for device 8086:340a = 2/0
> [    1.987426] [drm] enabling PCIE gen 2 link speeds, disable with
> radeon.pcie_gen2=0
> [    1.987930] [drm] Loading BARTS Microcode
> [    1.990807] [drm] PCIE GART of 512M enabled (table at
> 0x0000000000040000).
> [    2.008503] [drm] ring test on 0 succeeded in 3 usecs
> [    2.009029] [drm] ib test on ring 0 succeeded in 0 usecs
> [    2.009728] [drm] Radeon Display Connectors
> [    2.009914] [drm] Connector 0:
> [    2.010103] [drm]   DP-1
> [    2.010283] [drm]   HPD4
> [    2.010464] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c
> 0x643c
> [    2.010734] [drm]   Encoders:
> [    2.010921] [drm]     DFP1: INTERNAL_UNIPHY2
> [    2.011112] [drm] Connector 1:
> [    2.011295] [drm]   HDMI-A-1
> [    2.011478] [drm]   HPD3
> [    2.011662] [drm]   DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c
> 0x646c
> [    2.011932] [drm]   Encoders:
> [    2.012119] [drm]     DFP2: INTERNAL_UNIPHY2
> [    2.012324] [drm] Connector 2:
> [    2.012512] [drm]   DVI-D-1
> [    2.012695] [drm]   HPD1
> [    2.012881] [drm]   DDC: 0x6480 0x6480 0x6484 0x6484 0x6488 0x6488 0x648c
> 0x648c
> [    2.013152] [drm]   Encoders:
> [    2.013340] [drm]     DFP3: INTERNAL_UNIPHY1
> [    2.013528] [drm] Connector 3:
> [    2.013712] [drm]   DVI-I-1
> [    2.013898] [drm]   HPD6
> [    2.014082] [drm]   DDC: 0x6470 0x6470 0x6474 0x6474 0x6478 0x6478 0x647c
> 0x647c
> [    2.014352] [drm]   Encoders:
> [    2.014538] [drm]     DFP4: INTERNAL_UNIPHY
> [    2.014724] [drm]     CRT1: INTERNAL_KLDSCP_DAC1
> [    2.015014] [drm] Internal thermal controller with fan control
> [    2.016370] [drm] radeon: power management initialized
> [    2.022137] [drm] DP sink type 0x13
> [    2.133666] [drm] fb mappable at 0xD0142000
> [    2.133793] [drm] vram apper at 0xD0000000
> [    2.133919] [drm] size 16384000
> [    2.134044] [drm] fb depth is 24
> [    2.134170] [drm]    pitch is 10240
> [    2.134358] fbcon: radeondrmfb (fb0) is primary device
> [    2.134901] [drm] crtc 0 using pll 0x2
> [    2.362257] [drm] crtc 1 using pll 0x1
> [    2.386709] [drm] crtc 2 using pll 0x0
> [    2.472275] fb0: radeondrmfb frame buffer device
> [    2.472300] drm: registered panic notifier
> [    2.472325] [drm] Initialized radeon 2.22.0 20080528 for 0000:08:00.0 on
> minor 0
> [   60.056358] [drm] DP sink type 0x13
> [   60.205905] [drm] DP sink type 0x13
> [   60.679305] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a
> PPLL
> [   60.679310] [drm] crtc 0 using pll 0xff
> [   60.789183] [drm] crtc 1 using pll 0x2
> [   60.819594] [drm] crtc 2 using pll 0x1
> [   61.926401] [drm] DP sink type 0x13
> [   73.022055] [drm] DP sink type 0x13
> [   73.567827] [drm] DP sink type 0x13
> [ 2654.041357] [drm] crtc 0 using pll 0x2
> [ 2654.146105] [drm] crtc 1 using pll 0x0
> [ 2654.193906] [drm] crtc 2 using pll 0x1
> [ 2699.743567] [drm] DP sink type 0x13
> [ 2699.892998] [drm] DP sink type 0x13
> [ 2699.982947] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a
> PPLL
> [ 2699.982950] [drm] crtc 0 using pll 0xff
> [ 2700.104885] [drm] crtc 1 using pll 0x2
> [ 2700.150563] [drm] crtc 2 using pll 0x1
> [ 2700.289148] [drm] DP sink type 0x13
> [ 2700.785181] [drm] DP sink type 0x13
> [ 2730.400834] [drm] crtc 0 using pll 0x2
> [ 2730.448034] [drm] crtc 1 using pll 0x0
> [ 2730.490630] [drm] crtc 2 using pll 0x1
> [ 2737.092937] [drm] DP sink type 0x13
> [ 2737.242505] [drm] DP sink type 0x13
> [ 2737.331883] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a
> PPLL
> [ 2737.331886] [drm] crtc 0 using pll 0xff
> [ 2737.453714] [drm] crtc 1 using pll 0x2
> [ 2737.509907] [drm] crtc 2 using pll 0x1
> [ 2737.645287] [drm] DP sink type 0x13
> [ 2738.207736] [drm] DP sink type 0x13
> [ 2763.766354] [drm] DP sink type 0x13
> [ 2763.882633] [drm] DP sink type 0x13
> [ 2764.118995] [drm] crtc 0 using pll 0x2
> [ 2764.223623] [drm] crtc 1 using pll 0x0
> [ 2764.273047] [drm] crtc 2 using pll 0x1
> [ 2767.566733] [drm] DP sink type 0x13
> 

I think I see the problem.  I think it's a limitation of the current current modesetting API.  The current API sets up each display independently which doesn't work so well if there are resource restrictions.  There shouldn't be any contention on your board since you are only using 2 non-DP displays.  It looks like X is mapping different crtcs to displays than the kernel fb.  Initially the kernel set up the follow:

> [    2.134901] [drm] crtc 0 using pll 0x2
> [    2.362257] [drm] crtc 1 using pll 0x1
> [    2.386709] [drm] crtc 2 using pll 0x0

Crtc 0 -> DCPLL -> DP
Crtc 1 -> PPLL2 -> DVI
Crtc 2 -> PPLL1 -> DVI

When X loads, it tried to set a different crtc to display mapping:

> [   60.679310] [drm] crtc 0 using pll 0xff
> [   60.789183] [drm] crtc 1 using pll 0x2
> [   60.819594] [drm] crtc 2 using pll 0x1

Crtc 0 -> INVALID -> DVI 0
Crtc 1 -> DCPLL -> DP
Crtc 2 -> PPLL2 -> DVI 1

Crtc 0 should have used PPLL1 or PPLL2, but they were already in use by crtc 1 and crtc  2 from the previous modeset.  Since the modeset API is not atomic, it doesn't have the whole picture.  I'm not sure of a good solution right now prior to the new atomic modeset API that is under discussion.  I guess we can revert the patch for 3.6.  For 3.7 I guess we need to validate the actual connector to make sure we aren't trying to set a different configuration relating to the same connector without first tearing down the first one.  In the interim, you should be able to work around it by disabling the non-DP outputs and then bringing than back up.

Alex

> > > 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.
> >
> > Yes.  Note that PLLs can only be shared for non-DP monitors if the clocks
> > are the same.
> That should be fine, two of the three monitors are the same.
> 
> Greetings,
> 
> Andres

Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Dan Carpenter]

This is fixed now?

regards,
dan carpenter

RE: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Deucher, Alexander]

> -----Original Message-----
> From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
> Sent: Wednesday, September 26, 2012 9:00 AM
> To: Deucher, Alexander
> Cc: Andres Freund; LKML; David Airlie; dri-devel@lists.freedesktop.org
> Subject: Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to
> allocate a PPLL
> 
> This is fixed now?

It should be.  The patch was reverted for 3.6.

Alex

> 
> regards,
> dan carpenter

Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Andres Freund]

On Wednesday, September 26, 2012 03:00:09 PM Dan Carpenter wrote:
> This is fixed now?
Its been reverted in 2f1f4d9b60396d2df4cff829bd5376ffc8ed9a2c which is in rc6.

On Monday, September 17, 2012 09:30:12 PM Deucher, Alexander wrote:
Sorry, I somehow accidentally marked your  email as read and thus didn't 
notice it.

> I think I see the problem.  I think it's a limitation of the current current 
modesetting API.  The current API sets up each display independently which 
doesn't work so well if there are resource restrictions.  There shouldn't be 
any contention on your board since you are only using 2 non-DP displays.  It 
looks like X is mapping different crtcs to displays than the kernel fb.  
Initially the kernel set up the follow:
> > [    2.134901] [drm] crtc 0 using pll 0x2
> > [    2.362257] [drm] crtc 1 using pll 0x1
> > [    2.386709] [drm] crtc 2 using pll 0x0
> 
> Crtc 0 -> DCPLL -> DP
> Crtc 1 -> PPLL2 -> DVI
> Crtc 2 -> PPLL1 -> DVI
> 
> When X loads, it tried to set a different crtc to display mapping:
> > [   60.679310] [drm] crtc 0 using pll 0xff
> > [   60.789183] [drm] crtc 1 using pll 0x2
> > [   60.819594] [drm] crtc 2 using pll 0x1
> 
> Crtc 0 -> INVALID -> DVI 0
> Crtc 1 -> DCPLL -> DP
> Crtc 2 -> PPLL2 -> DVI 1
> 
> Crtc 0 should have used PPLL1 or PPLL2, but they were already in use by
> crtc 1 and crtc  2 from the previous modeset.  Since the modeset API is
> not atomic, it doesn't have the whole picture.  I'm not sure of a good
> solution right now prior to the new atomic modeset API that is under
> discussion.  I guess we can revert the patch for 3.6.  For 3.7 I guess we
> need to validate the actual connector to make sure we aren't trying to set
> a different configuration relating to the same connector without first
> tearing down the first one.  In the interim, you should be able to work
> around it by disabling the non-DP outputs and then bringing than back up.
Thanks! That explanation makes sense. I can work around it just fine, starting 
X multiple times works which coincides nicely with your explanation.

The code in the 3.7 branch doesn't do that extended validation yet, rigth? If 
you want/need you can CC for testing once thats ready.

Greetings,

Andres

RE: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Deucher, Alexander]

> -----Original Message-----
> From: Andres Freund [mailto:andres@anarazel.de]
> Sent: Wednesday, September 26, 2012 9:41 AM
> To: Dan Carpenter
> Cc: Deucher, Alexander; LKML; David Airlie; dri-devel@lists.freedesktop.org
> Subject: Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to
> allocate a PPLL
> 
> On Wednesday, September 26, 2012 03:00:09 PM Dan Carpenter wrote:
> > This is fixed now?
> Its been reverted in 2f1f4d9b60396d2df4cff829bd5376ffc8ed9a2c which is in
> rc6.
> 
> On Monday, September 17, 2012 09:30:12 PM Deucher, Alexander wrote:
> Sorry, I somehow accidentally marked your  email as read and thus didn't
> notice it.
> 
> > I think I see the problem.  I think it's a limitation of the current current
> modesetting API.  The current API sets up each display independently which
> doesn't work so well if there are resource restrictions.  There shouldn't be
> any contention on your board since you are only using 2 non-DP displays.  It
> looks like X is mapping different crtcs to displays than the kernel fb.
> Initially the kernel set up the follow:
> > > [    2.134901] [drm] crtc 0 using pll 0x2
> > > [    2.362257] [drm] crtc 1 using pll 0x1
> > > [    2.386709] [drm] crtc 2 using pll 0x0
> >
> > Crtc 0 -> DCPLL -> DP
> > Crtc 1 -> PPLL2 -> DVI
> > Crtc 2 -> PPLL1 -> DVI
> >
> > When X loads, it tried to set a different crtc to display mapping:
> > > [   60.679310] [drm] crtc 0 using pll 0xff
> > > [   60.789183] [drm] crtc 1 using pll 0x2
> > > [   60.819594] [drm] crtc 2 using pll 0x1
> >
> > Crtc 0 -> INVALID -> DVI 0
> > Crtc 1 -> DCPLL -> DP
> > Crtc 2 -> PPLL2 -> DVI 1
> >
> > Crtc 0 should have used PPLL1 or PPLL2, but they were already in use by
> > crtc 1 and crtc  2 from the previous modeset.  Since the modeset API is
> > not atomic, it doesn't have the whole picture.  I'm not sure of a good
> > solution right now prior to the new atomic modeset API that is under
> > discussion.  I guess we can revert the patch for 3.6.  For 3.7 I guess we
> > need to validate the actual connector to make sure we aren't trying to set
> > a different configuration relating to the same connector without first
> > tearing down the first one.  In the interim, you should be able to work
> > around it by disabling the non-DP outputs and then bringing than back up.
> Thanks! That explanation makes sense. I can work around it just fine, starting
> X multiple times works which coincides nicely with your explanation.
> 
> The code in the 3.7 branch doesn't do that extended validation yet, rigth? If
> you want/need you can CC for testing once thats ready.

It should handle it now.  If you could test it that would be great.

Alex

Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Andres Freund]

On Wednesday, September 26, 2012 03:42:40 PM Deucher, Alexander wrote:
> > -----Original Message-----
> > From: Andres Freund [mailto:andres@anarazel.de]
> > Sent: Wednesday, September 26, 2012 9:41 AM
> > To: Dan Carpenter
> > Cc: Deucher, Alexander; LKML; David Airlie;
> > dri-devel@lists.freedesktop.org Subject: Re: radeon: Regression between
> > v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
> > 
> > On Wednesday, September 26, 2012 03:00:09 PM Dan Carpenter wrote:
> > > This is fixed now?
> > 
> > Its been reverted in 2f1f4d9b60396d2df4cff829bd5376ffc8ed9a2c which is in
> > rc6.
> > 
> > On Monday, September 17, 2012 09:30:12 PM Deucher, Alexander wrote:
> > Sorry, I somehow accidentally marked your  email as read and thus didn't
> > notice it.
> > 
> > > I think I see the problem.  I think it's a limitation of the current
> > > current
> > 
> > modesetting API.  The current API sets up each display independently
> > which doesn't work so well if there are resource restrictions.  There
> > shouldn't be any contention on your board since you are only using 2
> > non-DP displays.  It looks like X is mapping different crtcs to displays
> > than the kernel fb.
> > 
> > Initially the kernel set up the follow:
> > > > [    2.134901] [drm] crtc 0 using pll 0x2
> > > > [    2.362257] [drm] crtc 1 using pll 0x1
> > > > [    2.386709] [drm] crtc 2 using pll 0x0
> > > 
> > > Crtc 0 -> DCPLL -> DP
> > > Crtc 1 -> PPLL2 -> DVI
> > > Crtc 2 -> PPLL1 -> DVI
> > > 
> > > When X loads, it tried to set a different crtc to display mapping:
> > > > [   60.679310] [drm] crtc 0 using pll 0xff
> > > > [   60.789183] [drm] crtc 1 using pll 0x2
> > > > [   60.819594] [drm] crtc 2 using pll 0x1
> > > 
> > > Crtc 0 -> INVALID -> DVI 0
> > > Crtc 1 -> DCPLL -> DP
> > > Crtc 2 -> PPLL2 -> DVI 1
> > > 
> > > Crtc 0 should have used PPLL1 or PPLL2, but they were already in use by
> > > crtc 1 and crtc  2 from the previous modeset.  Since the modeset API is
> > > not atomic, it doesn't have the whole picture.  I'm not sure of a good
> > > solution right now prior to the new atomic modeset API that is under
> > > discussion.  I guess we can revert the patch for 3.6.  For 3.7 I guess
> > > we need to validate the actual connector to make sure we aren't trying
> > > to set a different configuration relating to the same connector
> > > without first tearing down the first one.  In the interim, you should
> > > be able to work around it by disabling the non-DP outputs and then
> > > bringing than back up.
> > 
> > Thanks! That explanation makes sense. I can work around it just fine,
> > starting X multiple times works which coincides nicely with your
> > explanation.
> > 
> > The code in the 3.7 branch doesn't do that extended validation yet,
> > rigth? If you want/need you can CC for testing once thats ready.
> 
> It should handle it now.  If you could test it that would be great.
Ok, just to be sure I tested Linus' tree and everything works fine there.

Unfortunately thats not the case with a straight merge of alexdeucher/drm-
next-3.7-wip. When gdm started *the first time* the DVI-connected (uhm, same 
sink type? Thats the saphire magic allowing more monitors on that type of 
graphics card?) I got a "unable to allocate a PPLL" error again. Logging 
in/starting a new X seems to fix that.

I have no clue, but the ppll allocation looks a bit funny:

[    1.845444] [drm] Initialized drm 1.1.0 20060810
[    1.869015] [drm] radeon defaulting to kernel modesetting.
[    1.892300] [drm] radeon kernel modesetting enabled.
[    1.915260] fb: conflicting fb hw usage radeondrmfb vs VGA16 VGA - removing 
generic driver
[    1.984746] [drm] initializing kernel modesetting (BARTS 0x1002:0x6738 
0x174B:0x174B).
[    1.985248] [drm] register mmio base: 0xFBEC0000
[    1.985448] [drm] register mmio size: 131072
[    1.986784] [drm] Detected VRAM RAM=1024M, BAR=256M
[    1.986975] [drm] RAM width 256bits DDR
[    1.988070] [drm] radeon: 1024M of VRAM memory ready
[    1.988271] [drm] radeon: 512M of GTT memory ready.
[    1.988478] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[    1.988679] [drm] Driver supports precise vblank timestamp query.
[    1.989150] [drm] radeon: irq initialized.
[    1.989353] [drm] GART: num cpu pages 131072, num gpu pages 131072
[    1.990123] [drm] probing gen 2 caps for device 8086:340a = 2/0
[    1.990321] [drm] enabling PCIE gen 2 link speeds, disable with 
radeon.pcie_gen2=0
[    1.990825] [drm] Loading BARTS Microcode
[    3.246281] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
[    3.263969] [drm] ring test on 0 succeeded in 3 usecs
[    3.264466] [drm] ib test on ring 0 succeeded in 0 usecs
[    3.265168] [drm] Radeon Display Connectors
[    3.265357] [drm] Connector 0:
[    3.265544] [drm]   DP-1
[    3.265746] [drm]   HPD4
[    3.265939] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 
0x643c
[    3.266206] [drm]   Encoders:
[    3.266397] [drm]     DFP1: INTERNAL_UNIPHY2
[    3.266581] [drm] Connector 1:
[    3.266764] [drm]   HDMI-A-1
[    3.266950] [drm]   HPD3
[    3.267134] [drm]   DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 
0x646c
[    3.267405] [drm]   Encoders:
[    3.267593] [drm]     DFP2: INTERNAL_UNIPHY2
[    3.267781] [drm] Connector 2:
[    3.267966] [drm]   DVI-D-1
[    3.268151] [drm]   HPD1
[    3.268335] [drm]   DDC: 0x6480 0x6480 0x6484 0x6484 0x6488 0x6488 0x648c 
0x648c
[    3.268609] [drm]   Encoders:
[    3.268795] [drm]     DFP3: INTERNAL_UNIPHY1
[    3.268982] [drm] Connector 3:
[    3.269180] [drm]   DVI-I-1
[    3.269366] [drm]   HPD6
[    3.269551] [drm]   DDC: 0x6470 0x6470 0x6474 0x6474 0x6478 0x6478 0x647c 
0x647c
[    3.269827] [drm]   Encoders:
[    3.270011] [drm]     DFP4: INTERNAL_UNIPHY
[    3.270197] [drm]     CRT1: INTERNAL_KLDSCP_DAC1
[    3.270487] [drm] Internal thermal controller with fan control
[    3.271844] [drm] radeon: power management initialized
[    3.282342] [drm] DP sink type 0x13
[    3.393981] [drm] fb mappable at 0xD0142000
[    3.394107] [drm] vram apper at 0xD0000000
[    3.394235] [drm] size 16384000
[    3.394362] [drm] fb depth is 24
[    3.394487] [drm]    pitch is 10240
[    3.394674] fbcon: radeondrmfb (fb0) is primary device
[    3.395218] [drm] crtc 0 using pll 0x2
[    3.622463] [drm] crtc 1 using pll 0x1
[    3.646905] [drm] crtc 2 using pll 0x0
[    3.732561] fb0: radeondrmfb frame buffer device
[    3.732585] drm: registered panic notifier
[    3.732610] [drm] Initialized radeon 2.24.0 20080528 for 0000:08:00.0 on 
minor 0
[   63.352921] [drm] DP sink type 0x13
[   63.499399] [drm] DP sink type 0x13
[   64.574889] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL
[   64.574895] [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on 
[CRTC:10]
[   64.574921] [drm] crtc 0 using pll 0x2
[   64.621784] [drm] crtc 1 using pll 0x2
[   64.712236] [drm] crtc 2 using pll 0x1
[   66.075266] [drm] DP sink type 0x13
[   76.365428] [drm] DP sink type 0x13
[   77.217333] [drm] DP sink type 0x13
[  163.510596] [drm] DP sink type 0x13
[  163.637010] [drm] DP sink type 0x13
[  163.734771] [drm] crtc 0 using pll 0x0
[  163.794607] [drm] crtc 0 using pll 0x2
[  163.860506] [drm] crtc 1 using pll 0x0
[  163.912786] [drm] crtc 2 using pll 0x1
[  167.204356] [drm] DP sink type 0x13
[  477.651100] [drm] DP sink type 0x13

Greetings,

Andres

Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Alex Deucher]

On Thu, Sep 27, 2012 at 2:46 AM, Andres Freund <andres@anarazel.de> wrote:
> On Wednesday, September 26, 2012 03:42:40 PM Deucher, Alexander wrote:
>> > -----Original Message-----
>> > From: Andres Freund [mailto:andres@anarazel.de]
>> > Sent: Wednesday, September 26, 2012 9:41 AM
>> > To: Dan Carpenter
>> > Cc: Deucher, Alexander; LKML; David Airlie;
>> > dri-devel@lists.freedesktop.org Subject: Re: radeon: Regression between
>> > v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
>> >
>> > On Wednesday, September 26, 2012 03:00:09 PM Dan Carpenter wrote:
>> > > This is fixed now?
>> >
>> > Its been reverted in 2f1f4d9b60396d2df4cff829bd5376ffc8ed9a2c which is in
>> > rc6.
>> >
>> > On Monday, September 17, 2012 09:30:12 PM Deucher, Alexander wrote:
>> > Sorry, I somehow accidentally marked your  email as read and thus didn't
>> > notice it.
>> >
>> > > I think I see the problem.  I think it's a limitation of the current
>> > > current
>> >
>> > modesetting API.  The current API sets up each display independently
>> > which doesn't work so well if there are resource restrictions.  There
>> > shouldn't be any contention on your board since you are only using 2
>> > non-DP displays.  It looks like X is mapping different crtcs to displays
>> > than the kernel fb.
>> >
>> > Initially the kernel set up the follow:
>> > > > [    2.134901] [drm] crtc 0 using pll 0x2
>> > > > [    2.362257] [drm] crtc 1 using pll 0x1
>> > > > [    2.386709] [drm] crtc 2 using pll 0x0
>> > >
>> > > Crtc 0 -> DCPLL -> DP
>> > > Crtc 1 -> PPLL2 -> DVI
>> > > Crtc 2 -> PPLL1 -> DVI
>> > >
>> > > When X loads, it tried to set a different crtc to display mapping:
>> > > > [   60.679310] [drm] crtc 0 using pll 0xff
>> > > > [   60.789183] [drm] crtc 1 using pll 0x2
>> > > > [   60.819594] [drm] crtc 2 using pll 0x1
>> > >
>> > > Crtc 0 -> INVALID -> DVI 0
>> > > Crtc 1 -> DCPLL -> DP
>> > > Crtc 2 -> PPLL2 -> DVI 1
>> > >
>> > > Crtc 0 should have used PPLL1 or PPLL2, but they were already in use by
>> > > crtc 1 and crtc  2 from the previous modeset.  Since the modeset API is
>> > > not atomic, it doesn't have the whole picture.  I'm not sure of a good
>> > > solution right now prior to the new atomic modeset API that is under
>> > > discussion.  I guess we can revert the patch for 3.6.  For 3.7 I guess
>> > > we need to validate the actual connector to make sure we aren't trying
>> > > to set a different configuration relating to the same connector
>> > > without first tearing down the first one.  In the interim, you should
>> > > be able to work around it by disabling the non-DP outputs and then
>> > > bringing than back up.
>> >
>> > Thanks! That explanation makes sense. I can work around it just fine,
>> > starting X multiple times works which coincides nicely with your
>> > explanation.
>> >
>> > The code in the 3.7 branch doesn't do that extended validation yet,
>> > rigth? If you want/need you can CC for testing once thats ready.
>>
>> It should handle it now.  If you could test it that would be great.
> Ok, just to be sure I tested Linus' tree and everything works fine there.
>
> Unfortunately thats not the case with a straight merge of alexdeucher/drm-
> next-3.7-wip. When gdm started *the first time* the DVI-connected (uhm, same
> sink type? Thats the saphire magic allowing more monitors on that type of
> graphics card?) I got a "unable to allocate a PPLL" error again. Logging
> in/starting a new X seems to fix that.

So you have a xorg.conf with a hardcoded configuration?  If so can you
send it to me?

Thanks,

Alex

Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Andres Freund]

On Thursday, September 27, 2012 03:14:31 PM Alex Deucher wrote:
> On Thu, Sep 27, 2012 at 2:46 AM, Andres Freund <andres@anarazel.de> wrote:
> > On Wednesday, September 26, 2012 03:42:40 PM Deucher, Alexander wrote:
> >> > -----Original Message-----
> >> > From: Andres Freund [mailto:andres@anarazel.de]
> >> > Sent: Wednesday, September 26, 2012 9:41 AM
> >> > To: Dan Carpenter
> >> > Cc: Deucher, Alexander; LKML; David Airlie;
> >> > dri-devel@lists.freedesktop.org Subject: Re: radeon: Regression
> >> > between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
> >> > 
> >> > On Wednesday, September 26, 2012 03:00:09 PM Dan Carpenter wrote:
> >> > > This is fixed now?
> >> > 
> >> > Its been reverted in 2f1f4d9b60396d2df4cff829bd5376ffc8ed9a2c which is
> >> > in rc6.
> >> > 
> >> > On Monday, September 17, 2012 09:30:12 PM Deucher, Alexander wrote:
> >> > Sorry, I somehow accidentally marked your  email as read and thus
> >> > didn't notice it.
> >> > 
> >> > > I think I see the problem.  I think it's a limitation of the current
> >> > > current
> >> > 
> >> > modesetting API.  The current API sets up each display independently
> >> > which doesn't work so well if there are resource restrictions.  There
> >> > shouldn't be any contention on your board since you are only using 2
> >> > non-DP displays.  It looks like X is mapping different crtcs to
> >> > displays than the kernel fb.
> >> > 
> >> > Initially the kernel set up the follow:
> >> > > > [    2.134901] [drm] crtc 0 using pll 0x2
> >> > > > [    2.362257] [drm] crtc 1 using pll 0x1
> >> > > > [    2.386709] [drm] crtc 2 using pll 0x0
> >> > > 
> >> > > Crtc 0 -> DCPLL -> DP
> >> > > Crtc 1 -> PPLL2 -> DVI
> >> > > Crtc 2 -> PPLL1 -> DVI
> >> > > 
> >> > > When X loads, it tried to set a different crtc to display mapping:
> >> > > > [   60.679310] [drm] crtc 0 using pll 0xff
> >> > > > [   60.789183] [drm] crtc 1 using pll 0x2
> >> > > > [   60.819594] [drm] crtc 2 using pll 0x1
> >> > > 
> >> > > Crtc 0 -> INVALID -> DVI 0
> >> > > Crtc 1 -> DCPLL -> DP
> >> > > Crtc 2 -> PPLL2 -> DVI 1
> >> > > 
> >> > > Crtc 0 should have used PPLL1 or PPLL2, but they were already in use
> >> > > by crtc 1 and crtc  2 from the previous modeset.  Since the modeset
> >> > > API is not atomic, it doesn't have the whole picture.  I'm not sure
> >> > > of a good solution right now prior to the new atomic modeset API
> >> > > that is under discussion.  I guess we can revert the patch for 3.6.
> >> > >  For 3.7 I guess we need to validate the actual connector to make
> >> > > sure we aren't trying to set a different configuration relating to
> >> > > the same connector without first tearing down the first one.  In
> >> > > the interim, you should be able to work around it by disabling the
> >> > > non-DP outputs and then bringing than back up.
> >> > 
> >> > Thanks! That explanation makes sense. I can work around it just fine,
> >> > starting X multiple times works which coincides nicely with your
> >> > explanation.
> >> > 
> >> > The code in the 3.7 branch doesn't do that extended validation yet,
> >> > rigth? If you want/need you can CC for testing once thats ready.
> >> 
> >> It should handle it now.  If you could test it that would be great.
> > 
> > Ok, just to be sure I tested Linus' tree and everything works fine there.
> > 
> > Unfortunately thats not the case with a straight merge of
> > alexdeucher/drm- next-3.7-wip. When gdm started *the first time* the
> > DVI-connected (uhm, same sink type? Thats the saphire magic allowing
> > more monitors on that type of graphics card?) I got a "unable to
> > allocate a PPLL" error again. Logging in/starting a new X seems to fix
> > that.
> 
> So you have a xorg.conf with a hardcoded configuration?  If so can you
> send it to me?
Yes, but just setting the xrand positions:

Section "Monitor"
	Identifier   "DVI-1"
	Option	     "Primary"		"True"
EndSection

Section "Monitor"
	Identifier   "DVI-0"
        Option	     "RightOf"		"DVI-1"
	Option	     "Rotate"		"Left"
	Option	     "Primary"		"False"
EndSection

Section "Monitor"
	Identifier   "Displayport-0"
        Option	     "LeftOf"		"DVI-1"
	Option	     "Rotate"		"Left"
	Option	     "Primary"		"False"
EndSection


Andres

Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Alex Deucher]

[-- Attachment #1: Type: text/plain, Size: 4155 bytes --]

On Thu, Sep 27, 2012 at 9:23 AM, Andres Freund <andres@anarazel.de> wrote:
> On Thursday, September 27, 2012 03:14:31 PM Alex Deucher wrote:
>> On Thu, Sep 27, 2012 at 2:46 AM, Andres Freund <andres@anarazel.de> wrote:
>> > On Wednesday, September 26, 2012 03:42:40 PM Deucher, Alexander wrote:
>> >> > -----Original Message-----
>> >> > From: Andres Freund [mailto:andres@anarazel.de]
>> >> > Sent: Wednesday, September 26, 2012 9:41 AM
>> >> > To: Dan Carpenter
>> >> > Cc: Deucher, Alexander; LKML; David Airlie;
>> >> > dri-devel@lists.freedesktop.org Subject: Re: radeon: Regression
>> >> > between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
>> >> >
>> >> > On Wednesday, September 26, 2012 03:00:09 PM Dan Carpenter wrote:
>> >> > > This is fixed now?
>> >> >
>> >> > Its been reverted in 2f1f4d9b60396d2df4cff829bd5376ffc8ed9a2c which is
>> >> > in rc6.
>> >> >
>> >> > On Monday, September 17, 2012 09:30:12 PM Deucher, Alexander wrote:
>> >> > Sorry, I somehow accidentally marked your  email as read and thus
>> >> > didn't notice it.
>> >> >
>> >> > > I think I see the problem.  I think it's a limitation of the current
>> >> > > current
>> >> >
>> >> > modesetting API.  The current API sets up each display independently
>> >> > which doesn't work so well if there are resource restrictions.  There
>> >> > shouldn't be any contention on your board since you are only using 2
>> >> > non-DP displays.  It looks like X is mapping different crtcs to
>> >> > displays than the kernel fb.
>> >> >
>> >> > Initially the kernel set up the follow:
>> >> > > > [    2.134901] [drm] crtc 0 using pll 0x2
>> >> > > > [    2.362257] [drm] crtc 1 using pll 0x1
>> >> > > > [    2.386709] [drm] crtc 2 using pll 0x0
>> >> > >
>> >> > > Crtc 0 -> DCPLL -> DP
>> >> > > Crtc 1 -> PPLL2 -> DVI
>> >> > > Crtc 2 -> PPLL1 -> DVI
>> >> > >
>> >> > > When X loads, it tried to set a different crtc to display mapping:
>> >> > > > [   60.679310] [drm] crtc 0 using pll 0xff
>> >> > > > [   60.789183] [drm] crtc 1 using pll 0x2
>> >> > > > [   60.819594] [drm] crtc 2 using pll 0x1
>> >> > >
>> >> > > Crtc 0 -> INVALID -> DVI 0
>> >> > > Crtc 1 -> DCPLL -> DP
>> >> > > Crtc 2 -> PPLL2 -> DVI 1
>> >> > >
>> >> > > Crtc 0 should have used PPLL1 or PPLL2, but they were already in use
>> >> > > by crtc 1 and crtc  2 from the previous modeset.  Since the modeset
>> >> > > API is not atomic, it doesn't have the whole picture.  I'm not sure
>> >> > > of a good solution right now prior to the new atomic modeset API
>> >> > > that is under discussion.  I guess we can revert the patch for 3.6.
>> >> > >  For 3.7 I guess we need to validate the actual connector to make
>> >> > > sure we aren't trying to set a different configuration relating to
>> >> > > the same connector without first tearing down the first one.  In
>> >> > > the interim, you should be able to work around it by disabling the
>> >> > > non-DP outputs and then bringing than back up.
>> >> >
>> >> > Thanks! That explanation makes sense. I can work around it just fine,
>> >> > starting X multiple times works which coincides nicely with your
>> >> > explanation.
>> >> >
>> >> > The code in the 3.7 branch doesn't do that extended validation yet,
>> >> > rigth? If you want/need you can CC for testing once thats ready.
>> >>
>> >> It should handle it now.  If you could test it that would be great.
>> >
>> > Ok, just to be sure I tested Linus' tree and everything works fine there.
>> >
>> > Unfortunately thats not the case with a straight merge of
>> > alexdeucher/drm- next-3.7-wip. When gdm started *the first time* the
>> > DVI-connected (uhm, same sink type? Thats the saphire magic allowing
>> > more monitors on that type of graphics card?) I got a "unable to
>> > allocate a PPLL" error again. Logging in/starting a new X seems to fix
>> > that.
>>
>> So you have a xorg.conf with a hardcoded configuration?  If so can you
>> send it to me?
> Yes, but just setting the xrand positions:

Thanks.  I can't seem to reproduce it here, but I've pushed an updated
drm-next-3.7-wip which may help.  If not, can you apply the attached
patch and send me the output?

Thanks,

Alex

[-- Attachment #2: pll_debug.diff --]
[-- Type: application/octet-stream, Size: 4997 bytes --]

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index 96184d0..1f7e5fe 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1565,6 +1565,10 @@ static int radeon_get_shared_nondp_ppll(struct drm_crtc *crtc)
 		    !ENCODER_MODE_IS_DP(atombios_get_encoder_mode(test_radeon_crtc->encoder))) {
 			/* check if we are already driving this connector with another crtc */
 			if (test_radeon_crtc->connector == radeon_crtc->connector) {
+				DRM_INFO("crtc %d and crtc %d (0x%x) both driving %s\n",
+					 radeon_crtc->crtc_id, test_radeon_crtc->crtc_id,
+					 test_radeon_crtc->pll_id,
+					 drm_get_connector_name(radeon_crtc->connector));
 				/* if we are, return that pll */
 				if (test_radeon_crtc->pll_id != ATOM_PPLL_INVALID)
 					return test_radeon_crtc->pll_id;
@@ -1574,8 +1578,10 @@ static int radeon_get_shared_nondp_ppll(struct drm_crtc *crtc)
 			if ((crtc->mode.clock == test_crtc->mode.clock) &&
 			    (adjusted_clock == test_adjusted_clock) &&
 			    (radeon_crtc->ss_enabled == test_radeon_crtc->ss_enabled) &&
-			    (test_radeon_crtc->pll_id != ATOM_PPLL_INVALID))
+			    (test_radeon_crtc->pll_id != ATOM_PPLL_INVALID)) {
+				DRM_INFO("found pll 0x%x with matched clock\n", test_radeon_crtc->pll_id);
 				return test_radeon_crtc->pll_id;
+			}
 		}
 	}
 	return ATOM_PPLL_INVALID;
@@ -1631,6 +1637,7 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
 			/* UNIPHY A uses PPLL2 */
 			return ATOM_PPLL2;
 		else if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(radeon_crtc->encoder))) {
+			DRM_INFO("crtc %d is DP\n", radeon_crtc->crtc_id);
 			/* UNIPHY B/C/D/E/F */
 			if (rdev->clock.dp_extclk)
 				/* skip PPLL programming if using ext clock */
@@ -1642,6 +1649,7 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
 					return pll;
 			}
 		} else {
+			DRM_INFO("crtc %d is not DP\n", radeon_crtc->crtc_id);
 			/* use the same PPLL for all monitors with the same clock */
 			pll = radeon_get_shared_nondp_ppll(crtc);
 			if (pll != ATOM_PPLL_INVALID)
@@ -1649,6 +1657,7 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
 		}
 		/* UNIPHY B/C/D/E/F */
 		pll_in_use = radeon_get_pll_use_mask(crtc);
+		DRM_INFO("plls in use 0x%x\n", pll_in_use);
 		if (!(pll_in_use & (1 << ATOM_PPLL0)))
 			return ATOM_PPLL0;
 		if (!(pll_in_use & (1 << ATOM_PPLL1)))
@@ -1667,6 +1676,7 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
 		 * crtc virtual pixel clock.
 		 */
 		if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(radeon_crtc->encoder))) {
+			DRM_INFO("crtc %d is DP\n", radeon_crtc->crtc_id);
 			if (rdev->clock.dp_extclk)
 				/* skip PPLL programming if using ext clock */
 				return ATOM_PPLL_INVALID;
@@ -1683,6 +1693,7 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
 					return pll;
 			}
 		} else {
+			DRM_INFO("crtc %d is not DP\n", radeon_crtc->crtc_id);
 			/* use the same PPLL for all monitors with the same clock */
 			pll = radeon_get_shared_nondp_ppll(crtc);
 			if (pll != ATOM_PPLL_INVALID)
@@ -1690,6 +1701,7 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
 		}
 		/* all other cases */
 		pll_in_use = radeon_get_pll_use_mask(crtc);
+		DRM_INFO("plls in use 0x%x\n", pll_in_use);
 		if (!(pll_in_use & (1 << ATOM_PPLL2)))
 			return ATOM_PPLL2;
 		if (!(pll_in_use & (1 << ATOM_PPLL1)))
@@ -1703,11 +1715,13 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
 			 * DCE3: PPLL1 or PPLL2
 			 */
 			if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(radeon_crtc->encoder))) {
+				DRM_INFO("crtc %d is DP\n", radeon_crtc->crtc_id);
 				/* use the same PPLL for all DP monitors */
 				pll = radeon_get_shared_dp_ppll(crtc);
 				if (pll != ATOM_PPLL_INVALID)
 					return pll;
 			} else {
+				DRM_INFO("crtc %d is not DP\n", radeon_crtc->crtc_id);
 				/* use the same PPLL for all monitors with the same clock */
 				pll = radeon_get_shared_nondp_ppll(crtc);
 				if (pll != ATOM_PPLL_INVALID)
@@ -1715,6 +1729,7 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
 			}
 			/* all other cases */
 			pll_in_use = radeon_get_pll_use_mask(crtc);
+			DRM_INFO("plls in use 0x%x\n", pll_in_use);
 			if (!(pll_in_use & (1 << ATOM_PPLL2)))
 				return ATOM_PPLL2;
 			if (!(pll_in_use & (1 << ATOM_PPLL1)))
@@ -1811,7 +1826,11 @@ static bool atombios_crtc_mode_fixup(struct drm_crtc *crtc,
 	if (!atombios_crtc_prepare_pll(crtc, adjusted_mode))
 		return false;
 	/* pick pll */
+	DRM_INFO("== start crtc %d driving %s ==\n", radeon_crtc->crtc_id,
+		 drm_get_connector_name(radeon_crtc->connector));
 	radeon_crtc->pll_id = radeon_atom_pick_pll(crtc);
+	DRM_INFO("crtc %d using pll 0x%x\n", radeon_crtc->crtc_id, radeon_crtc->pll_id);
+	DRM_INFO("== end crtc %d ==\n", radeon_crtc->crtc_id);
 	/* if we can't get a PPLL for a non-DP encoder, fail */
 	if ((radeon_crtc->pll_id == ATOM_PPLL_INVALID) &&
 	    !ENCODER_MODE_IS_DP(atombios_get_encoder_mode(radeon_crtc->encoder)))

Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Alex Deucher]

On Thu, Sep 27, 2012 at 10:54 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Thu, Sep 27, 2012 at 9:23 AM, Andres Freund <andres@anarazel.de> wrote:
>> On Thursday, September 27, 2012 03:14:31 PM Alex Deucher wrote:
>>> On Thu, Sep 27, 2012 at 2:46 AM, Andres Freund <andres@anarazel.de> wrote:
>>> > On Wednesday, September 26, 2012 03:42:40 PM Deucher, Alexander wrote:
>>> >> > -----Original Message-----
>>> >> > From: Andres Freund [mailto:andres@anarazel.de]
>>> >> > Sent: Wednesday, September 26, 2012 9:41 AM
>>> >> > To: Dan Carpenter
>>> >> > Cc: Deucher, Alexander; LKML; David Airlie;
>>> >> > dri-devel@lists.freedesktop.org Subject: Re: radeon: Regression
>>> >> > between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
>>> >> >
>>> >> > On Wednesday, September 26, 2012 03:00:09 PM Dan Carpenter wrote:
>>> >> > > This is fixed now?
>>> >> >
>>> >> > Its been reverted in 2f1f4d9b60396d2df4cff829bd5376ffc8ed9a2c which is
>>> >> > in rc6.
>>> >> >
>>> >> > On Monday, September 17, 2012 09:30:12 PM Deucher, Alexander wrote:
>>> >> > Sorry, I somehow accidentally marked your  email as read and thus
>>> >> > didn't notice it.
>>> >> >
>>> >> > > I think I see the problem.  I think it's a limitation of the current
>>> >> > > current
>>> >> >
>>> >> > modesetting API.  The current API sets up each display independently
>>> >> > which doesn't work so well if there are resource restrictions.  There
>>> >> > shouldn't be any contention on your board since you are only using 2
>>> >> > non-DP displays.  It looks like X is mapping different crtcs to
>>> >> > displays than the kernel fb.
>>> >> >
>>> >> > Initially the kernel set up the follow:
>>> >> > > > [    2.134901] [drm] crtc 0 using pll 0x2
>>> >> > > > [    2.362257] [drm] crtc 1 using pll 0x1
>>> >> > > > [    2.386709] [drm] crtc 2 using pll 0x0
>>> >> > >
>>> >> > > Crtc 0 -> DCPLL -> DP
>>> >> > > Crtc 1 -> PPLL2 -> DVI
>>> >> > > Crtc 2 -> PPLL1 -> DVI
>>> >> > >
>>> >> > > When X loads, it tried to set a different crtc to display mapping:
>>> >> > > > [   60.679310] [drm] crtc 0 using pll 0xff
>>> >> > > > [   60.789183] [drm] crtc 1 using pll 0x2
>>> >> > > > [   60.819594] [drm] crtc 2 using pll 0x1
>>> >> > >
>>> >> > > Crtc 0 -> INVALID -> DVI 0
>>> >> > > Crtc 1 -> DCPLL -> DP
>>> >> > > Crtc 2 -> PPLL2 -> DVI 1
>>> >> > >
>>> >> > > Crtc 0 should have used PPLL1 or PPLL2, but they were already in use
>>> >> > > by crtc 1 and crtc  2 from the previous modeset.  Since the modeset
>>> >> > > API is not atomic, it doesn't have the whole picture.  I'm not sure
>>> >> > > of a good solution right now prior to the new atomic modeset API
>>> >> > > that is under discussion.  I guess we can revert the patch for 3.6.
>>> >> > >  For 3.7 I guess we need to validate the actual connector to make
>>> >> > > sure we aren't trying to set a different configuration relating to
>>> >> > > the same connector without first tearing down the first one.  In
>>> >> > > the interim, you should be able to work around it by disabling the
>>> >> > > non-DP outputs and then bringing than back up.
>>> >> >
>>> >> > Thanks! That explanation makes sense. I can work around it just fine,
>>> >> > starting X multiple times works which coincides nicely with your
>>> >> > explanation.
>>> >> >
>>> >> > The code in the 3.7 branch doesn't do that extended validation yet,
>>> >> > rigth? If you want/need you can CC for testing once thats ready.
>>> >>
>>> >> It should handle it now.  If you could test it that would be great.
>>> >
>>> > Ok, just to be sure I tested Linus' tree and everything works fine there.
>>> >
>>> > Unfortunately thats not the case with a straight merge of
>>> > alexdeucher/drm- next-3.7-wip. When gdm started *the first time* the
>>> > DVI-connected (uhm, same sink type? Thats the saphire magic allowing
>>> > more monitors on that type of graphics card?) I got a "unable to
>>> > allocate a PPLL" error again. Logging in/starting a new X seems to fix
>>> > that.
>>>
>>> So you have a xorg.conf with a hardcoded configuration?  If so can you
>>> send it to me?
>> Yes, but just setting the xrand positions:
>
> Thanks.  I can't seem to reproduce it here, but I've pushed an updated
> drm-next-3.7-wip which may help.  If not, can you apply the attached
> patch and send me the output?

Ok, I was finally able to reproduce your issue and it's working fine
here with my latest drm-next-3.7-wip branch.

Alex

Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

[Andres Freund]

On Thursday, September 27, 2012 06:19:53 PM Alex Deucher wrote:
> On Thu, Sep 27, 2012 at 10:54 AM, Alex Deucher <alexdeucher@gmail.com> 
wrote:
> > On Thu, Sep 27, 2012 at 9:23 AM, Andres Freund <andres@anarazel.de> wrote:
> >> On Thursday, September 27, 2012 03:14:31 PM Alex Deucher wrote:
> >>> On Thu, Sep 27, 2012 at 2:46 AM, Andres Freund <andres@anarazel.de> 
wrote:
> >>> > On Wednesday, September 26, 2012 03:42:40 PM Deucher, Alexander wrote:
> >>> >> > -----Original Message-----
> >>> >> > From: Andres Freund [mailto:andres@anarazel.de]
> >>> >> > Sent: Wednesday, September 26, 2012 9:41 AM
> >>> >> > To: Dan Carpenter
> >>> >> > Cc: Deucher, Alexander; LKML; David Airlie;
> >>> >> > dri-devel@lists.freedesktop.org Subject: Re: radeon: Regression
> >>> >> > between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
> >>> >> > 
> >>> >> > On Wednesday, September 26, 2012 03:00:09 PM Dan Carpenter wrote:
> >>> >> > > This is fixed now?
> >>> >> > 
> >>> >> > Its been reverted in 2f1f4d9b60396d2df4cff829bd5376ffc8ed9a2c
> >>> >> > which is in rc6.
> >>> >> > 
> >>> >> > On Monday, September 17, 2012 09:30:12 PM Deucher, Alexander
> >>> >> > wrote: Sorry, I somehow accidentally marked your  email as read
> >>> >> > and thus didn't notice it.
> >>> >> > 
> >>> >> > > I think I see the problem.  I think it's a limitation of the
> >>> >> > > current current
> >>> >> > 
> >>> >> > modesetting API.  The current API sets up each display
> >>> >> > independently which doesn't work so well if there are resource
> >>> >> > restrictions.  There shouldn't be any contention on your board
> >>> >> > since you are only using 2 non-DP displays.  It looks like X is
> >>> >> > mapping different crtcs to displays than the kernel fb.
> >>> >> > 
> >>> >> > Initially the kernel set up the follow:
> >>> >> > > > [    2.134901] [drm] crtc 0 using pll 0x2
> >>> >> > > > [    2.362257] [drm] crtc 1 using pll 0x1
> >>> >> > > > [    2.386709] [drm] crtc 2 using pll 0x0
> >>> >> > > 
> >>> >> > > Crtc 0 -> DCPLL -> DP
> >>> >> > > Crtc 1 -> PPLL2 -> DVI
> >>> >> > > Crtc 2 -> PPLL1 -> DVI
> >>> >> > > 
> >>> >> > > When X loads, it tried to set a different crtc to display mapping:
> >>> >> > > > [   60.679310] [drm] crtc 0 using pll 0xff
> >>> >> > > > [   60.789183] [drm] crtc 1 using pll 0x2
> >>> >> > > > [   60.819594] [drm] crtc 2 using pll 0x1
> >>> >> > > 
> >>> >> > > Crtc 0 -> INVALID -> DVI 0
> >>> >> > > Crtc 1 -> DCPLL -> DP
> >>> >> > > Crtc 2 -> PPLL2 -> DVI 1
> >>> >> > > 
> >>> >> > > Crtc 0 should have used PPLL1 or PPLL2, but they were already in
> >>> >> > > use by crtc 1 and crtc  2 from the previous modeset.  Since the
> >>> >> > > modeset API is not atomic, it doesn't have the whole picture. 
> >>> >> > > I'm not sure of a good solution right now prior to the new
> >>> >> > > atomic modeset API that is under discussion.  I guess we can
> >>> >> > > revert the patch for 3.6.
> >>> >> > > 
> >>> >> > >  For 3.7 I guess we need to validate the actual connector to
> >>> >> > >  make
> >>> >> > > 
> >>> >> > > sure we aren't trying to set a different configuration relating
> >>> >> > > to the same connector without first tearing down the first one.
> >>> >> > >  In the interim, you should be able to work around it by
> >>> >> > > disabling the non-DP outputs and then bringing than back up.
> >>> >> > 
> >>> >> > Thanks! That explanation makes sense. I can work around it just
> >>> >> > fine, starting X multiple times works which coincides nicely with
> >>> >> > your explanation.
> >>> >> > 
> >>> >> > The code in the 3.7 branch doesn't do that extended validation
> >>> >> > yet, rigth? If you want/need you can CC for testing once thats
> >>> >> > ready.
> >>> >> 
> >>> >> It should handle it now.  If you could test it that would be great.
> >>> > 
> >>> > Ok, just to be sure I tested Linus' tree and everything works fine
> >>> > there.
> >>> > 
> >>> > Unfortunately thats not the case with a straight merge of
> >>> > alexdeucher/drm- next-3.7-wip. When gdm started *the first time* the
> >>> > DVI-connected (uhm, same sink type? Thats the saphire magic allowing
> >>> > more monitors on that type of graphics card?) I got a "unable to
> >>> > allocate a PPLL" error again. Logging in/starting a new X seems to
> >>> > fix that.
> >>> 
> >>> So you have a xorg.conf with a hardcoded configuration?  If so can you
> >>> send it to me?
> >> 
> >> Yes, but just setting the xrand positions:
> > Thanks.  I can't seem to reproduce it here, but I've pushed an updated
> > drm-next-3.7-wip which may help.  If not, can you apply the attached
> > patch and send me the output?
> 
> Ok, I was finally able to reproduce your issue and it's working fine
> here with my latest drm-next-3.7-wip branch.
Sorry for the delay, I was on the road and couldn't easily test this remotely. 
Works fine!

Thanks,

Andres