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]

Date:	Wed, 26 Sep 2012 13:42:40 +0000
From:	"Deucher, Alexander" <Alexander.Deucher@....com>
To:	Andres Freund <andres@...razel.de>,
	Dan Carpenter <dan.carpenter@...cle.com>
CC:	LKML <linux-kernel@...r.kernel.org>,
	David Airlie <airlied@...ux.ie>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>
Subject: RE: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to
 allocate a PPLL

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

Alex


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