Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes

[Alex Deucher]

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.

Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-dce3-switch-back-to-old-pll-allocation-or.patch
Type: text/x-patch
Size: 3153 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/4eee7cd3/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-split-out-the-pll-disable-into-a-helper-f.patch
Type: text/x-patch
Size: 3600 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/4eee7cd3/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-drm-radeon-add-a-helper-to-check-if-a-pll-is-shared.patch
Type: text/x-patch
Size: 3166 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/4eee7cd3/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-drm-radeon-disable-the-pll-before-a-modeset.patch
Type: text/x-patch
Size: 910 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/4eee7cd3/attachment-0003.bin>