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

[Andy Furniss]

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.