On Thu, Sep 27, 2012 at 9:23 AM, Andres Freund <andres@xxxxxxxxxxx> 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@xxxxxxxxxxx> wrote: >> > On Wednesday, September 26, 2012 03:42:40 PM Deucher, Alexander wrote: >> >> > -----Original Message----- >> >> > From: Andres Freund [mailto:andres@xxxxxxxxxxx] >> >> > Sent: Wednesday, September 26, 2012 9:41 AM >> >> > To: Dan Carpenter >> >> > Cc: Deucher, Alexander; LKML; David Airlie; >> >> > dri-devel@xxxxxxxxxxxxxxxxxxxxx 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? Thanks, Alex
Attachment:
pll_debug.diff
Description: Binary data
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
