All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: jani.nikula@intel.com, manasi.d.navare@intel.com,
	ville.syrjala@linux.intel.com
Subject: [Intel-gfx] [PATCH 11/17] drm/i915/dp: add max data rate calculation for UHBR rates
Date: Wed, 18 Aug 2021 21:10:46 +0300	[thread overview]
Message-ID: <4182a477645f16f2f7efd2d5d0c21287c78bc4d9.1629310010.git.jani.nikula@intel.com> (raw)
In-Reply-To: <cover.1629310010.git.jani.nikula@intel.com>

DP 2.0 UHBR link rates always use 128b/132b channel encoding, which has
a different data bandwidth efficiency from 8b/10b. The computation is
slightly convoluted due to the units we use; this is all explained in
the added comment.

v2: Clarified comment (Manasi)

Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 drivers/gpu/drm/i915/display/intel_dp.c | 51 ++++++++++++++++++++++---
 drivers/gpu/drm/i915/display/intel_dp.h |  2 +-
 2 files changed, 46 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index 38d69e3d55ff..8e42c30b459c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -210,6 +210,10 @@ int intel_dp_max_lane_count(struct intel_dp *intel_dp)
 	return intel_dp->max_link_lane_count;
 }
 
+/*
+ * The required data bandwidth for a mode with given pixel clock and bpp. This
+ * is the required net bandwidth independent of the data bandwidth efficiency.
+ */
 int
 intel_dp_link_required(int pixel_clock, int bpp)
 {
@@ -217,16 +221,51 @@ intel_dp_link_required(int pixel_clock, int bpp)
 	return DIV_ROUND_UP(pixel_clock * bpp, 8);
 }
 
+/*
+ * Given a link rate and lanes, get the data bandwidth.
+ *
+ * Data bandwidth is the actual payload rate, which depends on the data
+ * bandwidth efficiency and the link rate.
+ *
+ * For 8b/10b channel encoding, SST and non-FEC, the data bandwidth efficiency
+ * is 80%. For example, for a 1.62 Gbps link, 1.62*10^9 bps * 0.80 * (1/8) =
+ * 162000 kBps. With 8-bit symbols, we have 162000 kHz symbol clock. Just by
+ * coincidence, the port clock in kHz matches the data bandwidth in kBps, and
+ * they equal the link bit rate in Gbps multiplied by 100000. (Note that this no
+ * longer holds for data bandwidth as soon as FEC or MST is taken into account!)
+ *
+ * For 128b/132b channel encoding, the data bandwidth efficiency is 96.71%. For
+ * example, for a 10 Gbps link, 10*10^9 bps * 0.9671 * (1/8) = 1208875
+ * kBps. With 32-bit symbols, we have 312500 kHz symbol clock. The value 1000000
+ * does not match the symbol clock, the port clock (not even if you think in
+ * terms of a byte clock), nor the data bandwidth. It only matches the link bit
+ * rate in units of 10000 bps.
+ */
 int
-intel_dp_max_data_rate(int max_link_clock, int max_lanes)
+intel_dp_max_data_rate(int max_link_rate, int max_lanes)
 {
-	/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
-	 * link rate that is generally expressed in Gbps. Since, 8 bits of data
-	 * is transmitted every LS_Clk per lane, there is no need to account for
-	 * the channel encoding that is done in the PHY layer here.
+	if (max_link_rate >= 1000000) {
+		/*
+		 * UHBR rates always use 128b/132b channel encoding, and have
+		 * 97.71% data bandwidth efficiency. Consider max_link_rate the
+		 * link bit rate in units of 10000 bps.
+		 */
+		int max_link_rate_kbps = max_link_rate * 10;
+		max_link_rate_kbps = DIV_ROUND_CLOSEST_ULL(max_link_rate_kbps * 9671, 10000);
+		max_link_rate = max_link_rate_kbps / 8;
+	}
+
+	/*
+	 * Lower than UHBR rates always use 8b/10b channel encoding, and have
+	 * 80% data bandwidth efficiency for SST non-FEC. However, this turns
+	 * out to be a nop by coincidence, and can be skipped:
+	 *
+	 *	int max_link_rate_kbps = max_link_rate * 10;
+	 *	max_link_rate_kbps = DIV_ROUND_CLOSEST_ULL(max_link_rate_kbps * 8, 10);
+	 *	max_link_rate = max_link_rate_kbps / 8;
 	 */
 
-	return max_link_clock * max_lanes;
+	return max_link_rate * max_lanes;
 }
 
 bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h b/drivers/gpu/drm/i915/display/intel_dp.h
index 1345d588fc6d..ae0f776bffab 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -88,7 +88,7 @@ bool intel_dp_source_supports_hbr3(struct intel_dp *intel_dp);
 
 bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp);
 int intel_dp_link_required(int pixel_clock, int bpp);
-int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
+int intel_dp_max_data_rate(int max_link_rate, int max_lanes);
 bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp);
 bool intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state,
 			    const struct drm_connector_state *conn_state);
-- 
2.20.1


  parent reply	other threads:[~2021-08-18 18:12 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18 18:10 [Intel-gfx] [PATCH 00/17] drm/i915/dp: dp 2.0 enabling prep work Jani Nikula
2021-08-18 18:10 ` [Intel-gfx] [PATCH 01/17] drm/dp: add DP 2.0 UHBR link rate and bw code conversions Jani Nikula
2021-08-18 18:10   ` Jani Nikula
2021-08-19 16:51   ` Ville Syrjälä
2021-08-19 16:51     ` [Intel-gfx] " Ville Syrjälä
2021-08-18 18:10 ` [Intel-gfx] [PATCH 02/17] drm/dp: use more of the extended receiver cap Jani Nikula
2021-08-18 18:10   ` Jani Nikula
2021-08-18 18:10 ` [PATCH 03/17] drm/dp: add LTTPR DP 2.0 DPCD addresses Jani Nikula
2021-08-18 18:10   ` [Intel-gfx] " Jani Nikula
2021-08-18 18:10 ` [Intel-gfx] [PATCH 04/17] drm/dp: add helper for extracting adjust 128b/132b TX FFE preset Jani Nikula
2021-08-18 18:10   ` Jani Nikula
2021-08-19 17:30   ` Ville Syrjälä
2021-08-19 17:30     ` [Intel-gfx] " Ville Syrjälä
2021-08-18 18:10 ` [Intel-gfx] [PATCH 05/17] drm/i915/dp: use actual link rate values in struct link_config_limits Jani Nikula
2021-08-19 17:34   ` Ville Syrjälä
2021-08-18 18:10 ` [Intel-gfx] [PATCH 06/17] drm/i915/dp: read sink UHBR rates Jani Nikula
2021-08-19 17:45   ` Ville Syrjälä
2021-08-18 18:10 ` [Intel-gfx] [PATCH 07/17] drm/i915/dg2: add TRANS_DP2_CTL register definition Jani Nikula
2021-08-18 18:10 ` [Intel-gfx] [PATCH 08/17] drm/i915/dg2: add DG2+ TRANS_DDI_FUNC_CTL DP 2.0 128b/132b mode Jani Nikula
2021-08-18 18:10 ` [Intel-gfx] [PATCH 09/17] drm/i915/dg2: add TRANS_DP2_VFREQHIGH and TRANS_DP2_VFREQLOW Jani Nikula
2021-08-18 18:10 ` [Intel-gfx] [PATCH 10/17] drm/i915/dg2: add DG2 UHBR source rates Jani Nikula
2021-08-18 18:10 ` Jani Nikula [this message]
2021-08-18 18:10 ` [Intel-gfx] [PATCH 12/17] drm/i915/dp: use 128b/132b TPS2 for UHBR+ link rates Jani Nikula
2021-08-18 18:10 ` [Intel-gfx] [PATCH 13/17] drm/i915/dp: select 128b/132b channel encoding for UHBR rates Jani Nikula
2021-08-19 17:49   ` Ville Syrjälä
2021-08-20  6:36     ` Jani Nikula
2021-08-18 18:10 ` [Intel-gfx] [PATCH 14/17] drm/i915/dg2: configure TRANS_DP2_CTL for DP 2.0 Jani Nikula
2021-08-18 18:10 ` [Intel-gfx] [PATCH 15/17] drm/i915/dg2: use 128b/132b transcoder DDI mode Jani Nikula
2021-08-19 17:54   ` Ville Syrjälä
2021-08-18 18:10 ` [Intel-gfx] [PATCH 16/17] drm/i915/dg2: configure TRANS_DP2_VFREQ{HIGH, LOW} for 128b/132b Jani Nikula
2021-08-18 18:10 ` [Intel-gfx] [PATCH 17/17] drm/i915/dg2: update link training " Jani Nikula
2021-08-18 20:19 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: dp 2.0 enabling prep work Patchwork
2021-08-18 20:21 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-08-18 20:49 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork

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=4182a477645f16f2f7efd2d5d0c21287c78bc4d9.1629310010.git.jani.nikula@intel.com \
    --to=jani.nikula@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=manasi.d.navare@intel.com \
    --cc=ville.syrjala@linux.intel.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 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.