From 302983e9059e9ef5de3ca7671918eeb237c5971e Mon Sep 17 00:00:00 2001
From: Adam Jackson <ajax@redhat.com>
Date: Wed, 13 Jul 2011 16:32:32 -0400
Subject: [PATCH 1/3] drm/i915/pch: Fix integer math bugs in panel fitting
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Consider a 1600x900 panel, upscaling a 1360x768 mode, full-aspect. The
old math would give you:
scaled_width = 1600 * 768; /* 1228800 */
scaled_height = 1360 * 900; /* 1224000 */
if (scaled_width > scaled_height) { /* pillarbox, and true */
width = 1224000 / 768; /* int(1593.75) = 1593 */
x = (1600 - 1593 + 1) / 2; /* 4 */
y = 0;
height = 768;
} /* ... */
This is broken. The total width of scanout would then be 1593 + 4 + 4,
or 1601, which is wider than the panel itself. The hardware very
dutifully implements this, and you end up with a black 45° diagonal from
the top-left corner to the bottom edge of the screen. It's a cool
effect and all, but not what you wanted. Similar things happen for the
letterbox case.
The problem is that you have an integer number of pixels, which means
it's usually impossible to upscale equally on both axes. 1360/768 is
1.7708, 1600/900 is 1.7777. Since we're constrained on the one axis,
the other one wants to come out as an even number of pixels (the panel
is almost certainly even on both axes, and the x/y offsets will be
applied on both sides). In the math above, if 'width' comes out even,
rounding down is correct; if it's odd, you'd rather round up. So just
increment width/height in those cases.
Tested on a Lenovo T500 (Ironlake).
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-By: Daniel Manrique <daniel.manrique@canonical.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38851
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Keith Packard <keithp@keithp.com>
---
drivers/gpu/drm/i915/intel_panel.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
index a06ff07a4d3b0..05f500cd9c246 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -83,11 +83,15 @@ intel_pch_panel_fitting(struct drm_device *dev,
u32 scaled_height = mode->hdisplay * adjusted_mode->vdisplay;
if (scaled_width > scaled_height) { /* pillar */
width = scaled_height / mode->vdisplay;
+ if (width & 1)
+ width++;
x = (adjusted_mode->hdisplay - width + 1) / 2;
y = 0;
height = adjusted_mode->vdisplay;
} else if (scaled_width < scaled_height) { /* letter */
height = scaled_width / mode->hdisplay;
+ if (height & 1)
+ height++;
y = (adjusted_mode->vdisplay - height + 1) / 2;
x = 0;
width = adjusted_mode->hdisplay;
From 81055854d096959898fdc17ed11729eb019eff07 Mon Sep 17 00:00:00 2001
From: Adam Jackson <ajax@redhat.com>
Date: Thu, 21 Jul 2011 17:48:37 -0400
Subject: [PATCH 2/3] drm/i915/dp: Explicitly disable symbol scrambling while
training
The DP spec says training patterns 1 and 2 are to be sent non-scrambled,
and the GPU docs claim that happens (or at least, there's no explicit
scrambling control). But the sink may be confused if we don't
explicitly tell it what we're doing, so play it safe.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
---
drivers/gpu/drm/i915/intel_dp.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1c3a36feaf69d..8aecb072466b6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1370,7 +1370,8 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
reg = DP | DP_LINK_TRAIN_PAT_1;
if (!intel_dp_set_link_train(intel_dp, reg,
- DP_TRAINING_PATTERN_1))
+ DP_TRAINING_PATTERN_1 |
+ DP_LINK_SCRAMBLING_DISABLE))
break;
/* Set training pattern 1 */
@@ -1445,7 +1446,8 @@ intel_dp_complete_link_train(struct intel_dp *intel_dp)
/* channel eq pattern */
if (!intel_dp_set_link_train(intel_dp, reg,
- DP_TRAINING_PATTERN_2))
+ DP_TRAINING_PATTERN_2 |
+ DP_LINK_SCRAMBLING_DISABLE))
break;
udelay(400);
From e85194641bec56179dcf5e1704ce5c6bf30340c6 Mon Sep 17 00:00:00 2001
From: Adam Jackson <ajax@redhat.com>
Date: Thu, 21 Jul 2011 17:48:38 -0400
Subject: [PATCH 3/3] drm/i915/dp: Don't turn CPT DP ports on too early
The docs say the port has to come on in training pattern 1; at this
point, though, ->DP is in normal mode. The intent here is to wait
until the port is in fact sending data, but that doesn't happen since
we've broken the sequence the hardware expects, and the vblank wait will
time out and kvetch in the log.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
---
drivers/gpu/drm/i915/intel_dp.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8aecb072466b6..dcc7ae6d41419 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1334,10 +1334,16 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
u32 reg;
uint32_t DP = intel_dp->DP;
- /* Enable output, wait for it to become active */
- I915_WRITE(intel_dp->output_reg, intel_dp->DP);
- POSTING_READ(intel_dp->output_reg);
- intel_wait_for_vblank(dev, intel_crtc->pipe);
+ /*
+ * On CPT we have to enable the port in training pattern 1, which
+ * will happen below in intel_dp_set_link_train. Otherwise, enable
+ * the port and wait for it to become active.
+ */
+ if (!HAS_PCH_CPT(dev)) {
+ I915_WRITE(intel_dp->output_reg, intel_dp->DP);
+ POSTING_READ(intel_dp->output_reg);
+ intel_wait_for_vblank(dev, intel_crtc->pipe);
+ }
/* Write the link configuration data */
intel_dp_aux_native_write(intel_dp, DP_LINK_BW_SET,