From bedbbe6af4bee062c7d035c424826190aab602a0 Mon Sep 17 00:00:00 2001 From: Chris Park Date: Fri, 10 May 2019 13:34:30 -0400 Subject: [PATCH] drm/amd/display: Move link functions from dc to dc_link [Why] link-specific functions should reside in dc_link.c [How] Move them there. Signed-off-by: Chris Park Reviewed-by: Charlene Liu Acked-by: Leo Li Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 27 +++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c index 1af06637fdda..2a9f4661540c 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c @@ -3053,6 +3053,33 @@ uint32_t dc_link_bandwidth_kbps( link_bw_kbps *= 8; /* 8 bits per byte*/ link_bw_kbps *= link_setting->lane_count; +#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT + if (link->dpcd_caps.fec_cap.bits.FEC_CAPABLE) { + /* Account for FEC overhead. + * We have to do it based on caps, + * and not based on FEC being set ready, + * because FEC is set ready too late in + * the process to correctly be picked up + * by mode enumeration. + * + * There's enough zeros at the end of 'kbps' + * that make the below operation 100% precise + * for our purposes. + * 'long long' makes it work even for HDMI 2.1 + * max bandwidth (and much, much bigger bandwidths + * than that, actually). + * + * NOTE: Reducing link BW by 3% may not be precise + * because it may be a stream BT that increases by 3%, and so + * 1/1.03 = 0.970873 factor should have been used instead, + * but the difference is minimal and is in a safe direction, + * which all works well around potential ambiguity of DP 1.4a spec. + */ + long long fec_link_bw_kbps = link_bw_kbps * 970LL; + link_bw_kbps = (uint32_t)(fec_link_bw_kbps / 1000LL); + } +#endif + return link_bw_kbps; } -- 2.30.2