Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup

[Alex Deucher]

2008/6/24 Jiri Palecek <jpalecek at web.de>:
> Tags: fixed-upstream
>
> On Monday 23 June 2008 21:55:21 Alex Deucher wrote:
>> On Sun, Jun 22, 2008 at 10:47 AM, Jiří Paleček <jpalecek at web.de> wrote:
>> > Hello,
>> >
>> > I prepared a new (better) version of the patch. Please consider applying
>> > it or otherwise fixing the bug.
>> >
>> > Some comments:
>> >
>> > The first patch causes abort instead of hangs when PLL computation fails.
>> >
>> > The second changes the algorithm so it doesn't miss any solution which
>> > might be better than current and finds a solution iff there is one.
>> >
>> > The third patch removes a condition which seems to be bogus for me - it
>> > cannot force pll->reference_div in the solution, but will probably poison
>> > the solution with a bad solution having good ref_div, for the next
>> > ref_div to override it with a better solution.
>>
>> Thanks for doing this!
>
> You're welcome. It wouldn't have been possible without your suggestion.
>
>> I've pushed a variation on this set of patches
>> to ati git master (72feaa37ea07620f5f2ead438dbc72a1c8883cd3).  Please
>> let me know if you are still having problems.
>
> Looking (and working) good. Just some non-issues (at least for me):
>
> +               if ((best_vco == 0 && error < best_error) ||
> +                   (best_vco != 0 &&
> +                    (error < best_error - 100 ||
> +                     (abs(error - best_error) < 100 && vco_diff < best_vco_diff )))) {
>
> Is the "100" on the previous line 100 meaning 100 Hz, or a relict from the
> "10kHz-unit" times (meaning 1 MHz)?

100 Hz.

>
> +               } else if (current_freq == freq) {
>
> Can this ever work? I mean, if the condition is true, error is zero so the
> previous "if" likely matched. How should the preference for low ref_divs work?

It only happens if the frequency is an exact match and there are
several possible combinations available.  The error will be 0, but the
vco diff becomes the same as the vco so the first part of that "if"
block fails.  It happens more often on newer cards as they have a
wider range of available dividers.  For example on some of my cards,
there are quite a few matches for 65 Mhz (27 Mhz ref clk):
260, 6, 18 (feedback, ref, post)
650, 27, 10
715, 27, 11
260, 9, 12
650, 18, 15
130, 3, 18
etc.

For whatever reason, monitors seem to prefer the clk generated with a
lower ref divider, given these choices.

> For example, I have pixelclock of 175 MHz, which is
>
>  2.7 MHz/27(ref)*350(feedback)/2
>
> Would it be better to have
>
>  2.7 MHz/3*194/1 = 174.6 MHz?
>

hard to say.  Generally, an exact match would be preferred.  The flag
really is really just to help choose a preferred set of dividers when
you have more than one match.  Monitors (especially DVI/HDMI) are
rather picky.

> Last, would it be possible to make it also consider the maximum pixelclock of
> the CRT (for example, if you want the maximum pixelclock of the CRT, the
> algorithm might get a higher frequency)?

The algorithm is limited by the range of clocks that the pll is able
to produce.  Presumably mode validation has culled out any modes that
the monitor is not able to handle.

Alex

>
> I don't think any of these are important, they're just suggestions.
>
> Regards
>    Jiri Palecek
>
>
>
>
>
>