Revert 4deb8a793907015dbf821d2e343d9527a5ae2512 plus a one liner

Change the error bounds on the pll search, since it is *far* too tight for
some things. This commit didn't hit the linux kernel yet, but adam jackson's
commit message on the patch sent to intel-gfx was:

From: Adam Jackson <ajax@redhat.com>
Subject: [Intel-gfx] [PATCH] drm/i915: Make G4X-style PLL search more
permissive
To: intel-gfx@lists.freedesktop.org

Fixes an Ironlake laptop with a 68.940MHz 1280x800 panel and 120MHz SSC
reference clock.

More generally, the 0.488% tolerance used before is just too tight to
reliably find a PLL setting.  I extracted the search algorithm and
modified it to find the dot clocks with maximum error over the valid
range for the given output type:

http://people.freedesktop.org/~ajax/intel_g4x_find_best_pll.c

This gave:

Worst dotclock for Ironlake DAC refclk is 350000kHz (error 0.00571)
Worst dotclock for Ironlake SL-LVDS refclk is 102321kHz (error 0.00524)
Worst dotclock for Ironlake DL-LVDS refclk is 219642kHz (error 0.00488)
Worst dotclock for Ironlake SL-LVDS SSC refclk is 84374kHz (error
0.00529)
Worst dotclock for Ironlake DL-LVDS SSC refclk is 183035kHz (error
0.00488)
Worst dotclock for G4X SDVO refclk is 50000kHz (error 0.17332)
Worst dotclock for G4X HDMI refclk is 334400kHz (error 0.00478)
Worst dotclock for G4X SL-LVDS refclk is 95571kHz (error 0.00449)
Worst dotclock for G4X DL-LVDS refclk is 224000kHz (error 0.00510)

The SDVO number looks a bit suspicious, which I haven't tracked down
yet.  But it's clear that the old threshold is too tight.

Signed-off-by: Adam Jackson <ajax@redhat.com>

still fixes reyk's x201 and doesn't fuck multihead on mine (which the
previous patch did).

Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>

0 files changed, 0 insertions, 0 deletions