From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v11 06/11] drm/i915/dp: Consider output_format while computing dsc bpp for mode_valid
Date: Fri, 17 Mar 2023 03:00:46 +0200 [thread overview]
Message-ID: <ZBO7vvuob0AHHmwZ@intel.com> (raw)
In-Reply-To: <20230314110415.2882484-7-ankit.k.nautiyal@intel.com>
On Tue, Mar 14, 2023 at 04:34:10PM +0530, Ankit Nautiyal wrote:
> During modevalid step, the pipe bpp is computed assuming RGB output
> format. When checking with DSC, consider the output_format and compute
> the input bpp for DSC appropriately.
>
> v2: For DP-MST we currently use RGB output format only, so continue
> using RGB while computing dsc_bpp for MST case.
>
> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 28 ++++++++++++++++-----
> drivers/gpu/drm/i915/display/intel_dp.h | 4 ++-
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
> 3 files changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index dcb3c2519041..499390c519ca 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1110,11 +1110,21 @@ intel_dp_mode_valid(struct drm_connector *_connector,
>
> if (HAS_DSC(dev_priv) &&
> drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)) {
> + int pipe_bpp;
> + enum intel_output_format output_format, sink_format;
> + const struct drm_display_info *info = &connector->base.display_info;
> +
> + if (drm_mode_is_420_only(info, mode))
> + sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> + else
> + sink_format = INTEL_OUTPUT_FORMAT_RGB;
I think I saw this same code duplicated somewhere else already.
Time for a intel_dp_sink_format()?
> +
> + output_format = intel_dp_output_format(connector, sink_format);
> /*
> * TBD pass the connector BPC,
> * for now U8_MAX so that max BPC on that platform would be picked
> */
> - int pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, U8_MAX);
> + pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, output_format, U8_MAX);
>
> /*
> * Output bpp is stored in 6.4 format so right shift by 4 to get the
> @@ -1454,12 +1464,15 @@ intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
> return -EINVAL;
> }
>
> -int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 max_req_bpc)
> +int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp,
> + enum intel_output_format output_format,
> + u8 max_req_bpc)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> int i, num_bpc;
> u8 dsc_bpc[3] = {0};
> u8 dsc_max_bpc;
> + int pipe_bpp = 0;
>
> /* Max DSC Input BPC for ICL is 10 and for TGL+ is 12 */
> if (DISPLAY_VER(i915) >= 12)
> @@ -1470,11 +1483,13 @@ int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 max_req_bpc)
> num_bpc = drm_dp_dsc_sink_supported_input_bpcs(intel_dp->dsc_dpcd,
> dsc_bpc);
> for (i = 0; i < num_bpc; i++) {
> - if (dsc_max_bpc >= dsc_bpc[i])
> - return dsc_bpc[i] * 3;
> + if (dsc_max_bpc >= dsc_bpc[i]) {
> + pipe_bpp = dsc_bpc[i] * 3;
> + break;
> + }
> }
>
> - return 0;
> + return intel_dp_output_bpp(output_format, pipe_bpp);
The pipe_bpp vs. output_bpp terms seem a bit confused now in the dsc
code.
In the non-compressed cases pipe_bpp does not include any
subsampling, output_bpp is the subsampled version.
What this dsc code seems to want is an intermediate value which
is the subsampled pipe_bpp that is the input to dsc compressor?
And output_bpp/dsc.compressed_bpp is then the final bpp coming
out of the compressor.
I think we should invent a consistent set of names for each so that
it's clear which value the code is concerned with.
> }
>
> static int intel_dp_source_dsc_version_minor(struct intel_dp *intel_dp)
> @@ -1588,7 +1603,8 @@ int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
> return -EINVAL;
>
> if (compute_pipe_bpp)
> - pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, conn_state->max_requested_bpc);
> + pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, pipe_config->output_format,
> + conn_state->max_requested_bpc);
This pipe_bpp gets plugged back into crtc_state->pipe_bpp later and
then it'll be the subsampled version. I don't think that is what we want
eg. for dithering setup and whatnot.
> else
> pipe_bpp = pipe_config->pipe_bpp;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h b/drivers/gpu/drm/i915/display/intel_dp.h
> index ef39e4f7a329..2f4136e43f38 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -102,7 +102,9 @@ void intel_read_dp_sdp(struct intel_encoder *encoder,
> struct intel_crtc_state *crtc_state,
> unsigned int type);
> bool intel_digital_port_connected(struct intel_encoder *encoder);
> -int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 dsc_max_bpc);
> +int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp,
> + enum intel_output_format output_format,
> + u8 dsc_max_bpc);
> u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> u32 link_clock, u32 lane_count,
> u32 mode_clock, u32 mode_hdisplay,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index ff0b821a901a..bdc5c53ccd75 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -917,7 +917,7 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector *connector,
> * TBD pass the connector BPC,
> * for now U8_MAX so that max BPC on that platform would be picked
> */
> - int pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, U8_MAX);
> + int pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, INTEL_OUTPUT_FORMAT_RGB, U8_MAX);
>
> if (drm_dp_sink_supports_fec(intel_dp->fec_capable)) {
> dsc_max_output_bpp =
> --
> 2.25.1
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2023-03-17 1:00 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-14 11:04 [Intel-gfx] [PATCH v11 00/11] Handle BPC for HDMI2.1 PCON without DSC1.2 sink and other fixes Ankit Nautiyal
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 01/11] drm/i915/display: Add new member to configure PCON color conversion Ankit Nautiyal
2023-03-17 0:24 ` Ville Syrjälä
2023-03-17 10:07 ` Nautiyal, Ankit K
2023-03-17 11:39 ` Ville Syrjälä
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 02/11] drm/i915/display: Add new member in intel_dp to store ycbcr420 passthrough cap Ankit Nautiyal
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 03/11] drm/i915/dp: Replace intel_dp.dfp members with the new crtc_state sink_format Ankit Nautiyal
2023-03-16 23:46 ` Ville Syrjälä
2023-03-17 10:48 ` Nautiyal, Ankit K
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 04/11] drm/i915/display: Use sink_format instead of ycbcr420_output flag Ankit Nautiyal
2023-03-17 0:25 ` Ville Syrjälä
2023-03-17 11:10 ` Nautiyal, Ankit K
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 05/11] drm/i915/dp: Rearrange check for illegal mode and comments in mode_valid Ankit Nautiyal
2023-03-17 0:28 ` Ville Syrjälä
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 06/11] drm/i915/dp: Consider output_format while computing dsc bpp for mode_valid Ankit Nautiyal
2023-03-17 1:00 ` Ville Syrjälä [this message]
2023-03-20 3:36 ` Nautiyal, Ankit K
2023-03-20 8:26 ` Ville Syrjälä
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 07/11] drm/i915/display: Add helper function to check if sink_format is 420 Ankit Nautiyal
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 08/11] drm/i915/dp: Avoid DSC with output_format YCBCR420 Ankit Nautiyal
2023-03-14 17:33 ` Manasi Navare
2023-03-16 11:20 ` Nautiyal, Ankit K
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 09/11] drm/i915/dp: Handle BPP where HDMI2.1 DFP doesn't support DSC Ankit Nautiyal
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 10/11] drm/i915/dp: Fix FRL BW check for HDMI2.1 DFP Ankit Nautiyal
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 11/11] drm/i915/dp: Add a wrapper to check frl/tmds downstream constraints Ankit Nautiyal
2023-03-14 15:41 ` [Intel-gfx] ✓ Fi.CI.BAT: success for Handle BPC for HDMI2.1 PCON without DSC1.2 sink and other fixes (rev12) Patchwork
2023-03-15 19:31 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=ZBO7vvuob0AHHmwZ@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=ankit.k.nautiyal@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
/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.