Alex Deucher wrote: > On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss <andyqos at ukfsn.org> wrote: >> Alex Deucher wrote: >>> >>> On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss <andyqos at 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 at 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 at amd.com> >> Cc: Markus Trippelsdorf <markus at 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.
