Date:	Tue, 2 Oct 2012 19:04:35 +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 06:19:53 PM Alex Deucher wrote:
> On Thu, Sep 27, 2012 at 10:54 AM, Alex Deucher <alexdeucher@...il.com> 
wrote:
> > On Thu, Sep 27, 2012 at 9:23 AM, Andres Freund <andres@...razel.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@...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:
> > 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
--
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/

Powered by blists - more mailing lists