[Intel-gfx] [PATCH 1/2] drm/i915/dp: Fix the math in intel_dp_link_required

[Adam Jackson]

On Fri, 2011-10-14 at 23:11 -0700, Keith Packard wrote:
> On Fri, 14 Oct 2011 12:43:49 -0400, Adam Jackson <ajax at redhat.com> wrote:
> 
> > The previous code was confused about units, which is pretty reasonable
> > given that the units themselves are confusing.
> 
> Thanks for actually figuring this out; the comment before that function
> should have indicated to any reader that I couldn't figure out what that
> computation should have been.
> 
> One question -- do you have an example of where the old computation
> failed and the new one works?

If you want "failed" to mean "refused to light something legal" you'd
have to go to something fairly extreme like 2560x1600R 30bpp:

wrong math: (268500 * 30 + 7) / 8  == 1006875
right math: (268500 * 30 + 9) / 10 == 805500

Remembering that the 4x2.7 limit is 864000.  But there are more mundane
cases where we'd just be wasting power by picking a higher link/lane
combo.  1920x1200R 24bpp:

wrong math: (154000 * 24 + 7) / 8  == 462000
right math: (154000 * 24 + 9) / 10 == 369600

Here we'd pick 4x1.62 instead of 2x2.7.  Which would work, assuming your
sink has all four lanes wired, but.  Unlike the first theoretical
example, this one I've actually tested (GM45 machine, HP LP2480zx
monitor):

[drm:drm_mode_debug_printmodeline], Modeline 28:"" 0 154000 1920 1968 2000 2080 1200 1203 1209 1235 0x0 0x9
[drm:intel_dp_mode_fixup], Display port link bw 0a lane count 2 clock 270000

---

The units end up being weird because of how we're choosing to encode the
lane rate in adjusted_mode->clock (all the literal '270000' in
intel_dp_link_clock() and friends).  It might be prettier to fix those
constants instead, but it's rather more invasive and doesn't really win
you anything.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20111017/3414ca28/attachment.sig>