public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andres Freund <andres@anarazel.de>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: "Deucher, Alexander" <Alexander.Deucher@amd.com>,
	LKML <linux-kernel@vger.kernel.org>,
	David Airlie <airlied@linux.ie>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
Date: Wed, 26 Sep 2012 15:41:09 +0200	[thread overview]
Message-ID: <201209261541.09835.andres@anarazel.de> (raw)
In-Reply-To: <20120926130009.GE28937@mwanda>

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.

Greetings,

Andres

  parent reply	other threads:[~2012-09-26 13:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-17 11:29 radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL Andres Freund
2012-09-17 13:16 ` Deucher, Alexander
2012-09-17 13:55   ` Andres Freund
2012-09-17 14:24     ` Deucher, Alexander
2012-09-17 17:15       ` Andres Freund
2012-09-17 19:30         ` Deucher, Alexander
2012-09-26 13:00           ` Dan Carpenter
2012-09-26 13:20             ` Deucher, Alexander
2012-09-26 13:41             ` Andres Freund [this message]
2012-09-26 13:42               ` Deucher, Alexander
2012-09-27  6:46                 ` Andres Freund
2012-09-27 13:14                   ` Alex Deucher
2012-09-27 13:23                     ` Andres Freund
2012-09-27 14:54                       ` Alex Deucher
2012-09-27 16:19                         ` Alex Deucher
2012-10-02 17:04                           ` Andres Freund

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201209261541.09835.andres@anarazel.de \
    --to=andres@anarazel.de \
    --cc=Alexander.Deucher@amd.com \
    --cc=airlied@linux.ie \
    --cc=dan.carpenter@oracle.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox