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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201209271523.49437.andres@anarazel.de>
Date:	Thu, 27 Sep 2012 15:23:49 +0200
From:	Andres Freund <andres@...razel.de>
To:	Alex Deucher <alexdeucher@...il.com>
Cc:	"Deucher, Alexander" <Alexander.Deucher@....com>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Dan Carpenter <dan.carpenter@...cle.com>
Subject: Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL

On Thursday, September 27, 2012 03:14:31 PM Alex Deucher wrote:
> On Thu, Sep 27, 2012 at 2:46 AM, Andres Freund <andres@...razel.de> wrote:
> > On Wednesday, September 26, 2012 03:42:40 PM Deucher, Alexander wrote:
> >> > -----Original Message-----
> >> > From: Andres Freund [mailto:andres@...razel.de]
> >> > Sent: Wednesday, September 26, 2012 9:41 AM
> >> > To: Dan Carpenter
> >> > Cc: Deucher, Alexander; LKML; David Airlie;
> >> > dri-devel@...ts.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/