Commit 48efd014 authored by Jani Nikula's avatar Jani Nikula

drm/i915/dp: add max data rate calculation for UHBR rates

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: default avatarManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8afd8d97a04c2d86c2dcadfed9f8e1f84272a13c.1629735412.git.jani.nikula@intel.com
parent e752d1f9
......@@ -212,6 +212,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)
{
......@@ -219,16 +223,52 @@ 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)
......
......@@ -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);
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment