[Bug 54381] New: [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[Bug 54381] New: [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL

[bugzilla-daemon]

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.