From: Adam Jackson <ajax@redhat.com>
To: Keith Packard <keithp@keithp.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915/dp: Fix the math in intel_dp_link_required
Date: Mon, 17 Oct 2011 13:03:02 -0400 [thread overview]
Message-ID: <1318870983.7630.39.camel@atropine> (raw)
In-Reply-To: <yunaa92zsuv.fsf@aiko.keithp.com>
[-- Attachment #1.1: Type: text/plain, Size: 1786 bytes --]
On Fri, 2011-10-14 at 23:11 -0700, Keith Packard wrote:
> On Fri, 14 Oct 2011 12:43:49 -0400, Adam Jackson <ajax@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
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2011-10-17 17:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-14 16:43 [PATCH 1/2] drm/i915/dp: Fix the math in intel_dp_link_required Adam Jackson
2011-10-14 16:43 ` [PATCH 2/2] drm/i915/dp: Remove eDP special cases from bandwidth checks Adam Jackson
2011-10-15 6:13 ` Keith Packard
2011-10-17 17:29 ` Adam Jackson
2012-05-10 18:40 ` Chris Wilson
2012-05-10 19:14 ` Daniel Vetter
2011-10-15 6:11 ` [PATCH 1/2] drm/i915/dp: Fix the math in intel_dp_link_required Keith Packard
2011-10-17 17:03 ` Adam Jackson [this message]
2011-10-17 22:46 ` Keith Packard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1318870983.7630.39.camel@atropine \
--to=ajax@redhat.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=keithp@keithp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox