On Fri, 2011-10-14 at 23:11 -0700, Keith Packard wrote: > On Fri, 14 Oct 2011 12:43:49 -0400, Adam Jackson <[email protected]> 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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
