From patchwork Mon Nov 5 15:56:52 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Deucher X-Patchwork-Id: 1699321 Return-Path: X-Original-To: patchwork-dri-devel@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by patchwork1.kernel.org (Postfix) with ESMTP id 8F4013FCDE for ; Mon, 5 Nov 2012 16:03:15 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 820A7A0209 for ; Mon, 5 Nov 2012 08:03:15 -0800 (PST) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by gabe.freedesktop.org (Postfix) with ESMTP id 9E0E09F79B for ; Mon, 5 Nov 2012 07:56:53 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id hj13so2353484wib.12 for ; Mon, 05 Nov 2012 07:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VCI85GlVeauTli91ZqUSGT6KfpxHObbIQn6u/E4BjK0=; b=bh5iI7QPv/JAt6/lYMgo66+IBnqsZoJXfSk9T/Hh2xF32CjZnGKJBgBTgiH422XW2L 72gyteqgPhXW5UDrUs/hjOjhWk59EGbBB9OPHbG1N1Wpd/nag5CfSSlYxVAbDcd0S1I6 wPwRlYlA9nnOGUBh6uhMyVUewwz2104MgCqC+6nl7TpQt3mDJo0WjqvSPlzEi9/RiebC eg4seQP9ZnQ+1GXR0A39pgOWYgXBNRsGbbZG+Qi/LCnOtwEw8YOjn6Zake9Pr8j+i7Nu OC3XaLT+ntOcS10fQrxFspH9T2r36NR383XSlmfCWVY9B5GLIT+Nt9ejuZtn6gOzAUue wxbw== MIME-Version: 1.0 Received: by 10.180.19.71 with SMTP id c7mr14093378wie.2.1352131012468; Mon, 05 Nov 2012 07:56:52 -0800 (PST) Received: by 10.216.220.94 with HTTP; Mon, 5 Nov 2012 07:56:52 -0800 (PST) In-Reply-To: <5096D785.80401@ukfsn.org> References: <50968952.6030406@ukfsn.org> <5096D785.80401@ukfsn.org> Date: Mon, 5 Nov 2012 10:56:52 -0500 Message-ID: Subject: Re: Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes From: Alex Deucher To: Andy Furniss Cc: dri-devel@lists.freedesktop.org X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+patchwork-dri-devel=patchwork.kernel.org@lists.freedesktop.org Errors-To: dri-devel-bounces+patchwork-dri-devel=patchwork.kernel.org@lists.freedesktop.org On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss wrote: > Alex Deucher wrote: >> >> On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss wrote: >>> >>> For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890 >>> and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off >>> and then turn TV on and - >>> >>> xrandr --output DVI-0 --auto >>> >>> to bring up the the TV and get a clone of monitor. >>> >>> This still works with drm-core-next but not with drm-fixes (todays or >>> from a >>> few days ago). >>> >>> With df I now loose the monitor with signal out of range when doing >>> above, >>> the TV output is OK. To get the monitor back I need to turn off TV, then >>> off/auto the monitor. >>> >>> xrandr --output DVI-0 --off >>> xrandr --output DVI-1 --off >>> xrandr --output DVI-1 --auto >>> >>> The output from xrandr while the monitor is showing signal out of range >>> looks normal. >>> >>> If I boot with the TV on it works OK. >> >> >> Can you bisect? > > > 29dbe3bcd2e28e71823febdca989d63d5c27d152 is the first bad commit > commit 29dbe3bcd2e28e71823febdca989d63d5c27d152 > Author: Alex Deucher > Date: Fri Oct 5 10:22:02 2012 -0400 > > drm/radeon: allocate PPLLs from low to high > > The order shouldn't matter, but there have been problems > reported on certain older asics. This behaves more > like the original code before the PPLL allocation > rework. > > Signed-off-by: Alex Deucher > Cc: Markus Trippelsdorf > > That's bizarre. That patch reverts the behavior back to the 3.6 and earlier kernel behavior. I guess it's some issue with the ordering of the modesetting programming sequence. I've attached a couple of things to try. The first patch is a simple fix. It just reverts back to the previous pll allocation order for discrete cards like yours: 0001-drm-radeon-dce3-switch-back-to-old-pll-allocation-or.patch The second set of patches implements a more complex fix which may help regardless of the order in which plls are allocated: 0001-drm-radeon-split-out-the-pll-disable-into-a-helper-f.patch 0002-drm-radeon-add-a-helper-to-check-if-a-pll-is-shared.patch 0003-drm-radeon-disable-the-pll-before-a-modeset.patch Can you see if the second set helps? If not, please try the first patch. Alex From f7a54adf9b66384afa16fcd00b4602f82e4b6ae9 Mon Sep 17 00:00:00 2001 From: Alex Deucher Date: Mon, 5 Nov 2012 10:44:53 -0500 Subject: [PATCH 3/3] drm/radeon: disable the pll before a modeset May fix display issues in certain cases. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/atombios_crtc.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index b072c1c..62a72fd 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -1901,6 +1901,7 @@ static void atombios_crtc_prepare(struct drm_crtc *crtc) atombios_lock_crtc(crtc, ATOM_ENABLE); atombios_crtc_dpms(crtc, DRM_MODE_DPMS_OFF); + atombios_disable_pll(crtc); } static void atombios_crtc_commit(struct drm_crtc *crtc) -- 1.7.7.5