https://bugzilla.kernel.org/show_bug.cgi?id=54381
Summary: [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL Product: Drivers Version: 2.5 Kernel Version: 3.7.2 and up Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri@kernel-bugs.osdl.org ReportedBy: rose@semkath.de Regression: No
I'm running a 3 monitor setup with a Radeon HD graphics card [Radeon HD 6000 Series]. I'm not using the proprietary drivers. Connectors are: 2 DVI and 1 HDMI. When I change the second DVI connection from a monitor to a projector and try to set the correct resolution (1920x1080) it fails with the following error message:
[15189.014994] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL [15189.015008] [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:12]
It changes the resolution but there are black areas at the sides and at the bottom of the displayed picture. It only happens if I connect the projector, not when the usual monitor is connected. This problem does not exist with kernel version 3.6.11.
$ scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes.
Linux semkath-desktop 3.8.0 #1 SMP PREEMPT Wed Feb 20 18:31:08 CET 2013 x86_64 AMD Phenom(tm) II X6 1090T Processor AuthenticAMD GNU/Linux
Gnu C 4.7.2 Gnu make 3.82 binutils 2.23.1 util-linux 2.22.2 mount debug module-init-tools 12 e2fsprogs 1.42.6 Linux C Library 2.16 Dynamic linker (ldd) 2.16 Procps UNKNOWN Net-tools 1.60_p20120127084908 Kbd 1.15.5 Sh-utils 8.21 Modules Loaded snd_aloop kvm_amd firewire_ohci k10temp i2c_piix4 firewire_core
https://bugzilla.kernel.org/show_bug.cgi?id=54381
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexdeucher@gmail.com
--- Comment #1 from Alex Deucher alexdeucher@gmail.com 2013-02-24 16:27:18 --- This is a hardware limitation. The hardware only has 2 PLLs for non-DisplayPort monitors. As such, the driver only supports 2 independent pixel clocks on non-DisplayPort monitors. If you have more than 2 non-DP monitors, it will only work if several of them share the same pixel clock (i.e., the monitors sharing a PLL have to display the same mode with the same pixel clock). Older kernels did not properly warn about exceeding these limitations.
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #2 from Sebastian Rose rose@semkath.de 2013-02-24 16:57:38 --- That explains why the 3 monitor setup works, but 2 monitors plus a projector don't: two of the monitors are the same. Interestingly enough, it works completely fine for any kernel < 3.7.0. I have been using this setup since at least a year or so and never had any problems with 3 different display units (until 3.7.0). Considering what you said that confuses me, since it shouldn't have worked as problem-free as it did, should it?
https://bugzilla.kernel.org/show_bug.cgi?id=54381
Sebastian Rose rose@semkath.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Kernel Version|3.7.2 and up |3.7.0 and up
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #3 from Alex Deucher alexdeucher@gmail.com 2013-02-24 23:14:49 --- (In reply to comment #2)
That explains why the 3 monitor setup works, but 2 monitors plus a projector don't: two of the monitors are the same. Interestingly enough, it works completely fine for any kernel < 3.7.0. I have been using this setup since at least a year or so and never had any problems with 3 different display units (until 3.7.0). Considering what you said that confuses me, since it shouldn't have worked as problem-free as it did, should it?
It probably worked by accident previously. Presumably the pixel clocks on the two monitors that were sharing a PLL were close enough that the monitors were ok with it. What modes are you running on the two monitors and projector?
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #4 from Sebastian Rose rose@semkath.de 2013-02-25 20:08:50 --- As per xrandr (projector NOT connected): DVI-0: 1280x1024 60.0*+ DVI-1: 1920x1200 60.0*+ HDMI-0: 1920x1200 60.0*+
The output DVI-1 with the projector connected: 1920x1080 60.0*+
Worked fine until 3.7.0.
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #5 from Alex Deucher alexdeucher@gmail.com 2013-02-25 20:16:03 --- (In reply to comment #4)
As per xrandr (projector NOT connected): DVI-0: 1280x1024 60.0*+ DVI-1: 1920x1200 60.0*+ HDMI-0: 1920x1200 60.0*+
The output DVI-1 with the projector connected: 1920x1080 60.0*+
Worked fine until 3.7.0.
Can you dump the full modelines with pixel clocks (xrandr --verbose)? I suspect the pixel clocks for 1920x1200 and 1920x1080 modes are close enough that one of the monitors was able to tolerate a slightly incorrect pixel clock. Some monitors are more tolerant than others. Projectors tend to be since they usually support a wide range of signals from various inputs.
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #6 from Sebastian Rose rose@semkath.de 2013-02-25 20:41:30 --- Projector connected at DVI-1. Usually connected to DVI-1 is a monitor identical to the one connected at HDMI-0.
DVI-0: 1280x1024 (0x59) 108.0MHz +HSync +VSync *current +preferred h: width 1280 start 1328 end 1440 total 1688 skew 0 clock 64.0KHz v: height 1024 start 1025 end 1028 total 1066 clock 60.0Hz HDMI-0: 1920x1200 (0x70) 154.0MHz +HSync -VSync *current +preferred h: width 1920 start 1968 end 2000 total 2080 skew 0 clock 74.0KHz v: height 1200 start 1203 end 1209 total 1235 clock 60.0Hz DVI-1: 1920x1080 (0x72) 148.5MHz +HSync +VSync *current +preferred h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.5KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.0Hz
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #7 from Alex Deucher alexdeucher@gmail.com 2013-02-25 20:58:37 --- 1920x1200 (0x70) 154.0MHz 1920x1080 (0x72) 148.5MHz
These two pixel clocks are close enough that your monitors seem to be able to deal with the slight difference. Unfortunately, not all monitors are so forgiving and and it wouldn't work if you picked a mode with a substantially different pixel clock. You just happened to get lucky.
https://bugzilla.kernel.org/show_bug.cgi?id=54381
Andrew Stubbs ams@codesourcery.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ams@codesourcery.com
--- Comment #8 from Andrew Stubbs ams@codesourcery.com --- I seem to have the exact same problem. :(
I've been using 12.04, and earlier, in a 3 monitor setup for ages now, and I'm really disappointed that it's stopped working with 13.04.
The clock description does ring true though because every now and again one of my monitors would say "Signal out of range", and I would shrug my shoulders, cycle it through the input settings, and it would work again.
Is there any way to hack the driver to get back the near-enough solution? It's a bit dirty, but I'm not sure I want to shell out £250 to fix the problem the clean way. Where would I look? Can you point me at the patch that "broke" it, perhaps?
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #9 from Andrew Stubbs ams@codesourcery.com --- Alternatively, would switching a monitor from DVI to VGA or HDMI help?
I currently have two DVI monitors, listed as "DisplayPort-1" and "DisplayPort-2", and one laptop display, listed as "LVDS". No two monitors have the same native resolution.
xrandr --query suggests that "DisplayPort-0" and "VGA-0" are unused. I presume that maps to the HDMI and VGA ports?
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #10 from Alex Deucher alexdeucher@gmail.com --- Sounds like your oem has a rather strange setup. Please attach your dmesg output.
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #11 from Andrew Stubbs ams@codesourcery.com --- It's a Dell Precision M4600 sitting in the docking station.
Apologies for the random Ubuntu version numbers. Not appropriate here. Unfortunately I don't actually know what kernel version I had before the upgrade.
I've now tried a VGA cable. The good news is that nothing crashes, spits error messages, or otherwise goes unstable. The bad news is that the widescreen monitor stretches the picture and loses the right edge of the picture. This happens whichever way around I hook them up; the picture is wrong in a different way with DVI vs. VGA, but both are wrong. I don't have a HDMI cable handy to try.
Anyway, I'll attach the dmesg data for you.
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #12 from Andrew Stubbs ams@codesourcery.com --- Created attachment 106911 --> https://bugzilla.kernel.org/attachment.cgi?id=106911&action=edit dmesg data from ams
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #13 from Andrew Stubbs ams@codesourcery.com --- The "problem" code appears to be in drivers/gpu/drm/radeon/atombios_crtc.c:radeon_get_shared_nondp_ppll or possibly radeon_get_shared_dp_ppll.
I've tried making the clock matching code slightly more permissive, but no luck yet. I'm going to try a few more experiments.
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #14 from Andrew Stubbs ams@codesourcery.com --- More observations:
About 1 time in 3 boots the driver will fail to allocate PPLLs at all, and Ubuntu 13.10 will not start lightdm login screen.
Having failed, I tend to get a run of failures, but two or three reboots is usually sufficient to get a working setup once more. There just seems to be a random factor in there somewhere.
Please note: in these instances I have one monitor configured to run in a reduced resolution, so clock matching should not be a problem. I suppose it might be less problematic were I running all three screens at their preferred, default resolution.
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #15 from Andrew Stubbs ams@codesourcery.com --- I fixed the problem now! (At least, for my own needs.)
The patch turns out to be very simple.
1. Disregard the mode setting (why does the PPLL care?)
2. Allow a little leeway in the frequency matching. I've allowed 10%, but another figure might be better.
I'll attach the patch in a moment. I'm not sure it's suitable for upstream without being configurable though?
https://bugzilla.kernel.org/show_bug.cgi?id=54381
--- Comment #16 from Andrew Stubbs ams@codesourcery.com --- Created attachment 108951 --> https://bugzilla.kernel.org/attachment.cgi?id=108951&action=edit Proposed patch
https://bugzilla.kernel.org/show_bug.cgi?id=54381
Andrew Stubbs ams@codesourcery.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #108951|0 |1 is obsolete| |
--- Comment #17 from Andrew Stubbs ams@codesourcery.com --- Created attachment 141471 --> https://bugzilla.kernel.org/attachment.cgi?id=141471&action=edit Proposed patch
This updated patch uses integer-only arithmetic. Apparently, that's necessary in 3.15, at least on Arch.
dri-devel@lists.freedesktop.org