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.
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?
Alex
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
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.
Alex
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.
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Andy Furniss