> -----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. Alex _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
