From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Subject: Re: Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes Date: Mon, 05 Nov 2012 17:54:50 +0000 Message-ID: <5097FD6A.5000008@ukfsn.org> References: <50968952.6030406@ukfsn.org> <5096D785.80401@ukfsn.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail.ukfsn.org (mx-out.ukfsn.org [77.75.108.125]) by gabe.freedesktop.org (Postfix) with ESMTP id 69AACA02C2 for ; Mon, 5 Nov 2012 09:54:55 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Alex Deucher Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org Alex Deucher wrote: > 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. The second set doesn't fix it. The first patch does.