| Message ID | CADnq5_Mi7uN+UhXesxaWXvCrwnXMGV9fpK2KBJbM1YqbthT1bQ@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Alex Deucher wrote: > On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss <andyqos@ukfsn.org> wrote: >> Alex Deucher wrote: >>> >>> On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss <andyqos@ukfsn.org> 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 <alexander.deucher@amd.com> >> 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 <alexander.deucher@amd.com> >> Cc: Markus Trippelsdorf <markus@trippelsdorf.de> >> >> > > 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.
From f7a54adf9b66384afa16fcd00b4602f82e4b6ae9 Mon Sep 17 00:00:00 2001 From: Alex Deucher <alexander.deucher@amd.com> 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 <alexander.deucher@amd.com> --- 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