Bug 21857

Created attachment 26076 [details] [review]
Xorg log where the monitor reports 'out or range'

Created attachment 26077 [details] [review]
Xorg log where the monitor works

Created attachment 26078 [details]
bios of that card.

Do any modes other than 1600x1200 work on the problematic DVI port?
xrandr --output DVI-0 --mode 1280x1024
or
xrandr --output DVI-0 --mode 1024x768

Also, you can try disabling coherent mode:
xrandr --output DVI-0 --set coherent_mode 0
xrandr --output DVI-0 --mode 1280x1024
xrandr --output DVI-0 --mode 1600x1200

(In reply to comment #4)
> Do any modes other than 1600x1200 work on the problematic DVI port?
> xrandr --output DVI-0 --mode 1280x1024
Works, but the monitor still claims 'out of range'

> or
> xrandr --output DVI-0 --mode 1024x768
Works, but the monitor still claims 'out of range'

> Also, you can try disabling coherent mode:
> xrandr --output DVI-0 --set coherent_mode 0
> xrandr --output DVI-0 --mode 1280x1024
> xrandr --output DVI-0 --mode 1600x1200
Playing with coherent_mode with the 1600x1200 mode does not change anything.
... out 'of range' and nothing visible.

Greetings

Mathias

Created attachment 30535 [details]
bunch of debug output

Hi,

Still this does not work - so I looked into that, but without having a real solution at hands.

Anyway I have made some observations that might help.

At first attached some plain register dumps and logs.
Attached here is the avivotool dump of all registers when dvi-1 is attached and when dvi-2 is attached. This is done with todays drm-next kernel module on a redhat rawhide from today. These are the dvi*-all-kms files.
Also included in this tar file are the fglrx avivodump files from a feora 10 install in the same hardware. these are the dvi*-all-fglrx files.
Additionally - I believe redundant but to be complete - the default avivotool regs dumps They also show interesting but for this problem irrelevant differences.
The atombios is included as well - I believe that this was already attached some time ago.
The files dvi*-debug contain the kernel dmesg output with drm debugging enabled of the kms boot.

Ok, so far the static things.

The interesting difference between the two register sets as from fglrx and from the kms code is the difference in the 0x0430 and 0x043c registers - which match the pll1 setup values of ref_div << 16 and the post_div from the kms code.

So comparing this register settings.
 
fglrx with dvi1 attached.
0x0430 = 4718592 means ref_div = 72 
0x043c = 3 means post_div = 3

fglrx with dvi2 attached.
0x0430 = 4718592 means ref_div = 72 
0x043c = 6 means post_div = 6

kms with dvi1 as well as dvi2 attached
0x0430 = 3145728 means ref_div = 48 
0x043c = 4 means post_div = 4

Where as noted in the first post here the monitor works when attached at dvi2 but tells 'out of range' when attached at dvi1. The same monitor with the same card works with fglrx on *both* dvi ports.
Interesting is the factor of two between the post_div values with fglrx.

Now, I can make the kms settings work with the following variants:

* With dvi1 attached replace the post_div value of 4 with post_div = 2 using avivotool. Voila, the monitor works with some minor flickering/sparkles, but that also happens at dvi2.

* Or take the two values that fglrx pokes into those two registers and poke those both values using avivotool into the r520 registers while running kms, and I will get a perfectly flicker/sparkle free picture with that monitor.

So, for the record, the reference clock is 2700(0). Also as far as I understand that fractional pll code, both settings match exactly the requested dot clock for the monitor. But fglrx seems to know that some values are better and takes an other set.
Also there is that factor of 2 that makes the monitor at dvi1 work, but that I could not really see a source of information that includes an additional factor of two for that output.

Ideas?
Help?
Patches?

Thanks in advance.

Mathias

Some monitors prefer certain combinations of pll dividers over other even though they produce the same target frequency.  The radeon driver has a set of pll flags to adjust the pll divider calculations to take this into account.  Take a look at atombios_crtc_set_pll() in atombios_crtc.c; we already adjust the flags for certain frequency ranges and asics.  You may try setting different combinations of those flags in atombios_crtc_set_pll().  The flags are defined in radeon_mode.h and you can see how they interact with the pll divider calculations in radeon_compute_pll() in radeon_diplay.c.

Hmm, yes I have seen that. And I expext that or something like that toe apropriate way to ajust the slight remaining flicker once the first output starts working at all.

But I fear to make that making dvi1 work is more than just slightly tweaking the dividers.

We are talking here about being off by a *factor* *of* *two*!

I fear that there is more wrong than just tweaking things.
Note that the output of the pll divider computation makes sense for the inputs AFICT. That holds for both outputs. But to make dvi1 display something I need to take the result that makes sense divide that result by 2 and than it magically works being than a factor of two away from what makes sense so far?

May be there is some additional frequency divider on some of the outputs?
May be we need to call an other bios call that tells about some more constraints?

Ideas?

Mathias

Created attachment 30543 [details] [review]
2x ppll for DVO

Ok, the problematic DVI port seems is the one driven by an external tmds chip connected via DVO.  That chip seems to want 2x the actual pixel clock.  This patch should do the trick.  I'll ask the bios guys what the deal is with DVO.

Created attachment 30571 [details] [review]
kms equivalent of your patch plus MinPixelClockPLL_Output fix

Ok,
According to your ddx change you have attached to the report, I have changed my currently more used kms code paths to do the same.

Additionally I have tried to find a way to tweak the pll computation to match fglrx behaviour and stumbled across the *MinPixelClockPLL_Output having two alteratives in the firmware info table starting with crev 2. Also looking into the atombios dump of the card in question, there is a value that might make more sense than the crev <= 1 value. The attached patch now makes use of that value and gets exactly the same pll settings that fglrx also used for this card.

The attached patch contains both changes and is sufficient to make my r520 work really well.

So, if your BIOS guys told you that the DVO *2 hack is correct, please apply the attached patch :)

Greetings

Mathias

Created attachment 30572 [details] [review]
alternate fix

Basically the pix clock is dependent on the configuration of the external tmds chip.  By default it appears atom sets it up to require 2x ppll clocking.  The attached patch should allow it to work without doubling the ppll.  Another alternative would be to change the configuration on the external chip, but that's probably a bit more complicated than the other solutions.  If you could test this patch as well, I'd appreciate it.

Good morning,

I am sorry to say, but for the ddx code:

The initial '2x ppll for DVO' patch works.
The new 'alternate fix' patch does not.

Greetings

Mathias

I've queued your min clock output fix for kms and committed a variation of it to the ddx for non-kms.  Just waiting on feedback from another user on the 2x ppll patch.

This read pretty much like it could be the problem I'm having with the kt690
board (#24456).  These proposed patches are not committed on the master branch?!
 

(In reply to comment #14)
> This read pretty much like it could be the problem I'm having with the kt690
> board (#24456).  These proposed patches are not committed on the master
> branch?!
> 

These patches do not affect your board as your board does not use the DVO port for DVI.

fix pushed to xf86-video-ati master:
5a0019126a57138ee506d9a66738c9e8b75cbb96
patch queued for kms as well.