From patchwork Wed Mar 6 19:31:01 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gwan-gyeong Mun X-Patchwork-Id: 10841679 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 766BD14DE for ; Wed, 6 Mar 2019 19:31:18 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 645C32EB0A for ; Wed, 6 Mar 2019 19:31:18 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 587622EB44; Wed, 6 Mar 2019 19:31:18 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id DB96B2EB69 for ; Wed, 6 Mar 2019 19:31:17 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id EEA576E1B4; Wed, 6 Mar 2019 19:31:16 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id B36C66E1B4 for ; Wed, 6 Mar 2019 19:31:14 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Mar 2019 11:31:14 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,448,1544515200"; d="scan'208";a="326035344" Received: from helsinki.fi.intel.com ([10.237.66.164]) by fmsmga005.fm.intel.com with ESMTP; 06 Mar 2019 11:31:12 -0800 From: Gwan-gyeong Mun To: intel-gfx@lists.freedesktop.org Date: Wed, 6 Mar 2019 21:31:01 +0200 Message-Id: <20190306193102.306-6-gwan-gyeong.mun@intel.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190306193102.306-1-gwan-gyeong.mun@intel.com> References: <20190306193102.306-1-gwan-gyeong.mun@intel.com> MIME-Version: 1.0 Subject: [Intel-gfx] [RFC v4 5/6] drm/i915/dp: Change a link bandwidth computation for DP YCbCr 4:2:0 output X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP All of the link bandwidth and Data M/N calculations were assumed a bpp as RGB format. But When we are using YCbCr 4:2:0 output format on DP, we should change bpp calculations as YCbCr 4:2:0 format. The pipe_bpp value was assumed RGB format, therefore, it was multiplied with 3. But YCbCr 4:2:0 requires a multiplier value to 1.5. Therefore we need to divide pipe_bpp to 2 while DP output uses YCbCr4:2:0 format. - RGB format bpp = bpc x 3 - YCbCr 4:2:0 format bpp = bpc x 1.5 And it adds missed bpc values for a programming of VSC Header. It only affects dp and edp port which use YCbCr 4:2:0 output format. And for now, it does not consider a use case of DSC + YCbCr 4:2:0. v2: Addressed review comments from Ville. Remove a changing of pipe_bpp on intel_ddi_set_pipe_settings(). Because the pipe is running at the full bpp, keep pipe_bpp as RGB even though YCbCr 4:2:0 output format is used. Add a link bandwidth computation for YCbCr4:2:0 output format. Signed-off-by: Gwan-gyeong Mun --- drivers/gpu/drm/i915/intel_dp.c | 64 +++++++++++++++++++++++++++++---- 1 file changed, 57 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 74f051428fb2..c6826cda8c5f 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1723,7 +1723,8 @@ void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock, struct link_config_limits { int min_clock, max_clock; int min_lane_count, max_lane_count; - int min_bpp, max_bpp; + int min_bpp, max_bpp, bpp_step; + bool is_ycbcr420; }; static bool intel_dp_source_supports_fec(struct intel_dp *intel_dp, @@ -1833,7 +1834,7 @@ intel_dp_compute_link_config_wide(struct intel_dp *intel_dp, int bpp, clock, lane_count; int mode_rate, link_clock, link_avail; - for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) { + for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= limits->bpp_step) { mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock, bpp); @@ -1847,7 +1848,10 @@ intel_dp_compute_link_config_wide(struct intel_dp *intel_dp, if (mode_rate <= link_avail) { pipe_config->lane_count = lane_count; - pipe_config->pipe_bpp = bpp; + if (limits->is_ycbcr420) + pipe_config->pipe_bpp = bpp * 2; + else + pipe_config->pipe_bpp = bpp; pipe_config->port_clock = link_clock; return 0; @@ -1869,7 +1873,7 @@ intel_dp_compute_link_config_fast(struct intel_dp *intel_dp, int bpp, clock, lane_count; int mode_rate, link_clock, link_avail; - for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) { + for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= limits->bpp_step) { mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock, bpp); @@ -1883,7 +1887,10 @@ intel_dp_compute_link_config_fast(struct intel_dp *intel_dp, if (mode_rate <= link_avail) { pipe_config->lane_count = lane_count; - pipe_config->pipe_bpp = bpp; + if (limits->is_ycbcr420) + pipe_config->pipe_bpp = bpp * 2; + else + pipe_config->pipe_bpp = bpp; pipe_config->port_clock = link_clock; return 0; @@ -2015,6 +2022,8 @@ intel_dp_compute_link_config(struct intel_encoder *encoder, struct link_config_limits limits; int common_len; int ret; + bool is_ycbcr420 = + pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ? true : false; common_len = intel_dp_common_len_rate_limit(intel_dp, intel_dp->max_link_rate); @@ -2030,6 +2039,20 @@ intel_dp_compute_link_config(struct intel_encoder *encoder, limits.min_bpp = 6 * 3; limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config); + limits.bpp_step = 2 * 3; + + limits.is_ycbcr420 = is_ycbcr420; + + if (is_ycbcr420) { + /* + * bpp value was assumed to RGB therefore it was multiplied + * with 3. But YCbCr 4:2:0 requires multiplier value to 1.5 + * therefore it divides pipe_bpp to 2. + */ + limits.min_bpp /= 2; + limits.max_bpp /= 2; + limits.bpp_step /= 2; + } if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] < DP_EDP_14) { /* @@ -2224,13 +2247,23 @@ intel_dp_compute_config(struct intel_encoder *encoder, intel_conn_state->broadcast_rgb == INTEL_BROADCAST_RGB_LIMITED; } - if (!pipe_config->dsc_params.compression_enable) - intel_link_compute_m_n(pipe_config->pipe_bpp, + if (!pipe_config->dsc_params.compression_enable) { + /* + * Basically, pipe_bpp value is assumed to RGB. + * And on the calculation of Data M and Data N, YCbCr 4:2:0 + * output format of the number of bytes per pixel will be half + * the number of bytes of RGB pixel. + */ + int pipe_bpp = pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ? + pipe_config->pipe_bpp / 2 : pipe_config->pipe_bpp; + + intel_link_compute_m_n(pipe_bpp, pipe_config->lane_count, adjusted_mode->crtc_clock, pipe_config->port_clock, &pipe_config->dp_m_n, constant_n); + } else intel_link_compute_m_n(pipe_config->dsc_params.compressed_bpp, pipe_config->lane_count, @@ -4458,6 +4491,23 @@ intel_pixel_encoding_setup_vsc(struct intel_dp *intel_dp, * 100b = 16bpc. */ vsc_sdp.DB17 = 0x1; + switch (crtc_state->pipe_bpp / 3) { + case 8: /* 8bpc */ + vsc_sdp.DB17 = 0x1; + break; + case 10: /* 10bpc */ + vsc_sdp.DB17 = 0x2; + break; + case 12: /* 12bpc */ + vsc_sdp.DB17 = 0x3; + break; + case 16: /* 16bpc */ + vsc_sdp.DB17 = 0x4; + break; + default: + DRM_DEBUG_KMS("Invalid bpp value '%d'\n", crtc_state->pipe_bpp); + break; + } /* * Content Type (Bits 2:0)