All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/2] drm/i915/dp: Fix the math in intel_dp_link_required
@ 2011-10-14 16:43 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:11 ` [PATCH 1/2] drm/i915/dp: Fix the math in intel_dp_link_required Keith Packard
  0 siblings, 2 replies; 9+ messages in thread
From: Adam Jackson @ 2011-10-14 16:43 UTC (permalink / raw)
  To: intel-gfx

The previous code was confused about units, which is pretty reasonable
given that the units themselves are confusing.

Signed-off-by: Adam Jackson <ajax@redhat.com>
---
 drivers/gpu/drm/i915/intel_dp.c |   26 +++++++++++++++++++++-----
 1 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44fef5e..4e62ff2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -175,9 +175,25 @@ intel_dp_link_clock(uint8_t link_bw)
 		return 162000;
 }
 
-/* I think this is a fiction */
+/*
+ * The units on the numbers in the next two are... bizarre.  Examples will
+ * make it clearer; this one parallels an example in the eDP spec.
+ *
+ * intel_dp_max_data_rate for one lane of 2.7GHz evaluates as:
+ *
+ *     270000 * 1 * 8 / 10 == 216000
+ *
+ * The actual data capacity of that configuration is 2.16Gbit/s, so the
+ * units are decakilobits.  ->clock in a drm_display_mode is in kilohertz -
+ * or equivalently, kilopixels per second - so for 1680x1050R it'd be
+ * 119000.  At 18bpp that's 2142000 kilobits per second.
+ *
+ * Thus the strange-looking division by 10 in intel_dp_link_required, to
+ * get the result in decakilobits instead of kilobits.
+ */
+
 static int
-intel_dp_link_required(struct drm_device *dev, struct intel_dp *intel_dp, int pixel_clock)
+intel_dp_link_required(struct intel_dp *intel_dp, int pixel_clock)
 {
 	struct drm_crtc *crtc = intel_dp->base.base.crtc;
 	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -186,7 +202,7 @@ intel_dp_link_required(struct drm_device *dev, struct intel_dp *intel_dp, int pi
 	if (intel_crtc)
 		bpp = intel_crtc->bpp;
 
-	return (pixel_clock * bpp + 7) / 8;
+	return (pixel_clock * bpp + 9) / 10;
 }
 
 static int
@@ -216,7 +232,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
 	/* only refuse the mode on non eDP since we have seen some weird eDP panels
 	   which are outside spec tolerances but somehow work by magic */
 	if (!is_edp(intel_dp) &&
-	    (intel_dp_link_required(connector->dev, intel_dp, mode->clock)
+	    (intel_dp_link_required(intel_dp, mode->clock)
 	     > intel_dp_max_data_rate(max_link_clock, max_lanes)))
 		return MODE_CLOCK_HIGH;
 
@@ -620,7 +636,7 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct drm_display_mode *mode,
 		for (clock = 0; clock <= max_clock; clock++) {
 			int link_avail = intel_dp_max_data_rate(intel_dp_link_clock(bws[clock]), lane_count);
 
-			if (intel_dp_link_required(encoder->dev, intel_dp, mode->clock)
+			if (intel_dp_link_required(intel_dp, mode->clock)
 					<= link_avail) {
 				intel_dp->link_bw = bws[clock];
 				intel_dp->lane_count = lane_count;
-- 
1.7.6.4

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH 2/2] drm/i915/dp: Remove eDP special cases from bandwidth checks
  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 ` Adam Jackson
  2011-10-15  6:13   ` Keith Packard
  2011-10-15  6:11 ` [PATCH 1/2] drm/i915/dp: Fix the math in intel_dp_link_required Keith Packard
  1 sibling, 1 reply; 9+ messages in thread
From: Adam Jackson @ 2011-10-14 16:43 UTC (permalink / raw)
  To: intel-gfx

These were just working around the math being wrong.

Signed-off-by: Adam Jackson <ajax@redhat.com>
---
 drivers/gpu/drm/i915/intel_dp.c |   20 ++------------------
 1 files changed, 2 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4e62ff2..08c3f84 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -229,11 +229,8 @@ intel_dp_mode_valid(struct drm_connector *connector,
 			return MODE_PANEL;
 	}
 
-	/* only refuse the mode on non eDP since we have seen some weird eDP panels
-	   which are outside spec tolerances but somehow work by magic */
-	if (!is_edp(intel_dp) &&
-	    (intel_dp_link_required(intel_dp, mode->clock)
-	     > intel_dp_max_data_rate(max_link_clock, max_lanes)))
+	if (intel_dp_link_required(intel_dp, mode->clock)
+	    > intel_dp_max_data_rate(max_link_clock, max_lanes))
 		return MODE_CLOCK_HIGH;
 
 	if (mode->clock < 10000)
@@ -650,19 +647,6 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct drm_display_mode *mode,
 		}
 	}
 
-	if (is_edp(intel_dp)) {
-		/* okay we failed just pick the highest */
-		intel_dp->lane_count = max_lane_count;
-		intel_dp->link_bw = bws[max_clock];
-		adjusted_mode->clock = intel_dp_link_clock(intel_dp->link_bw);
-		DRM_DEBUG_KMS("Force picking display port link bw %02x lane "
-			      "count %d clock %d\n",
-			      intel_dp->link_bw, intel_dp->lane_count,
-			      adjusted_mode->clock);
-
-		return true;
-	}
-
 	return false;
 }
 
-- 
1.7.6.4

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] drm/i915/dp: Fix the math in intel_dp_link_required
  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:11 ` Keith Packard
  2011-10-17 17:03   ` Adam Jackson
  1 sibling, 1 reply; 9+ messages in thread
From: Keith Packard @ 2011-10-15  6:11 UTC (permalink / raw)
  To: Adam Jackson, intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 515 bytes --]

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?

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 2/2] drm/i915/dp: Remove eDP special cases from bandwidth checks
  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
  0 siblings, 1 reply; 9+ messages in thread
From: Keith Packard @ 2011-10-15  6:13 UTC (permalink / raw)
  To: Adam Jackson, intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 328 bytes --]

On Fri, 14 Oct 2011 12:43:50 -0400, Adam Jackson <ajax@redhat.com> wrote:

> These were just working around the math being wrong.

One wonders whether this might break some machines which are currently
working. Should we emit an error or something if an eDP panel asks for
the impossible?

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] drm/i915/dp: Fix the math in intel_dp_link_required
  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
  2011-10-17 22:46     ` Keith Packard
  0 siblings, 1 reply; 9+ messages in thread
From: Adam Jackson @ 2011-10-17 17:03 UTC (permalink / raw)
  To: Keith Packard; +Cc: intel-gfx


[-- 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 2/2] drm/i915/dp: Remove eDP special cases from bandwidth checks
  2011-10-15  6:13   ` Keith Packard
@ 2011-10-17 17:29     ` Adam Jackson
  2012-05-10 18:40       ` Chris Wilson
  0 siblings, 1 reply; 9+ messages in thread
From: Adam Jackson @ 2011-10-17 17:29 UTC (permalink / raw)
  To: Keith Packard; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 1831 bytes --]

On Fri, 2011-10-14 at 23:13 -0700, Keith Packard wrote:
> On Fri, 14 Oct 2011 12:43:50 -0400, Adam Jackson <ajax@redhat.com> wrote:
> 
> > These were just working around the math being wrong.
> 
> One wonders whether this might break some machines which are currently
> working. Should we emit an error or something if an eDP panel asks for
> the impossible?

Probably, but I think in cases where that happens we should be
considering the driver to be broken before the panel.  No one's going to
manufacture hardware that can't run Windows.

The patch adding that check - fe27d53e5c597ee5ba5d72a29d517091f244e974 -
references bug #28070.  Relevant attachments:

https://bugs.freedesktop.org/attachment.cgi?id=35584
[drm:drm_mode_debug_printmodeline], Modeline 25:"1920x1080" 60 137700
1920 1968 2000 2066 1080 1083 1088 1111 0x48 0xa
[drm:intel_dp_mode_fixup], Display port link bw 06 lane count 2 clock 162000

https://bugs.freedesktop.org/attachment.cgi?id=35585
eDP block: type 6
	Power Sequence: T3 3000 T7 400 T9 2000 T10 500 T12 5000
	Panel color depth: 18bpp
	eDP sDRRs MSA timing delay: 0
	Link params:
		rate: 1.62G
		lanes: x1 mode
		pre-emphasis: none
		vswing: 0.4V

Old math: (137700 * 18 + 7) / 8  == 309825
New math: (137700 * 18 + 9) / 10 == 247860

I'm coming to believe that the eDP block's link parameters are nonsense
and we should just trust DPCD.  Which seems like a solid plan
regardless.  Sadly that dmesg doesn't include a DPCD dump, but, the
threshold table looks like this:

Rate / Lanes	1	2	4
1.62GHz		129600	259200	518400
2.7GHZ		216000	432000	864000

Note that the corrected math gives us a data rate that fits in 2x1.62,
but the old math requires either more lanes or a higher rate.  So I
suspect the machine wasn't broken in the first place.

- 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] drm/i915/dp: Fix the math in intel_dp_link_required
  2011-10-17 17:03   ` Adam Jackson
@ 2011-10-17 22:46     ` Keith Packard
  0 siblings, 0 replies; 9+ messages in thread
From: Keith Packard @ 2011-10-17 22:46 UTC (permalink / raw)
  To: Adam Jackson; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 434 bytes --]

On Mon, 17 Oct 2011 13:03:02 -0400, Adam Jackson <ajax@redhat.com> wrote:

> [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

Ok, nice to see that you've actually tested a marginal case and had it
work :-)

Acked-by: Keith Packard <keithp@keithp.com>

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 2/2] drm/i915/dp: Remove eDP special cases from bandwidth checks
  2011-10-17 17:29     ` Adam Jackson
@ 2012-05-10 18:40       ` Chris Wilson
  2012-05-10 19:14         ` Daniel Vetter
  0 siblings, 1 reply; 9+ messages in thread
From: Chris Wilson @ 2012-05-10 18:40 UTC (permalink / raw)
  To: Adam Jackson, Keith Packard; +Cc: intel-gfx

On Mon, 17 Oct 2011 13:29:18 -0400, Adam Jackson <ajax@redhat.com> wrote:
> On Fri, 2011-10-14 at 23:13 -0700, Keith Packard wrote:
> > On Fri, 14 Oct 2011 12:43:50 -0400, Adam Jackson <ajax@redhat.com> wrote:
> > 
> > > These were just working around the math being wrong.
> > 
> > One wonders whether this might break some machines which are currently
> > working. Should we emit an error or something if an eDP panel asks for
> > the impossible?
> 
> Probably, but I think in cases where that happens we should be
> considering the driver to be broken before the panel.  No one's going to
> manufacture hardware that can't run Windows.

Sigh, This patch did introduce a number of regressions, notably
https://bugs.freedesktop.org/show_bug.cgi?id=45801
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 2/2] drm/i915/dp: Remove eDP special cases from bandwidth checks
  2012-05-10 18:40       ` Chris Wilson
@ 2012-05-10 19:14         ` Daniel Vetter
  0 siblings, 0 replies; 9+ messages in thread
From: Daniel Vetter @ 2012-05-10 19:14 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

On Thu, May 10, 2012 at 07:40:23PM +0100, Chris Wilson wrote:
> On Mon, 17 Oct 2011 13:29:18 -0400, Adam Jackson <ajax@redhat.com> wrote:
> > On Fri, 2011-10-14 at 23:13 -0700, Keith Packard wrote:
> > > On Fri, 14 Oct 2011 12:43:50 -0400, Adam Jackson <ajax@redhat.com> wrote:
> > > 
> > > > These were just working around the math being wrong.
> > > 
> > > One wonders whether this might break some machines which are currently
> > > working. Should we emit an error or something if an eDP panel asks for
> > > the impossible?
> > 
> > Probably, but I think in cases where that happens we should be
> > considering the driver to be broken before the panel.  No one's going to
> > manufacture hardware that can't run Windows.
> 
> Sigh, This patch did introduce a number of regressions, notably
> https://bugs.freedesktop.org/show_bug.cgi?id=45801

To clarify, the first patch (fix dp math) broke stuff, not the second one
(rip out edp special case) for this reporter.
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2012-05-10 19:13 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2011-10-17 22:46     ` Keith Packard

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.