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 v10 03/13] drm/i915/dp: Add Scaler constraint for YCbCr420 output
Date: Wed, 8 Mar 2023 17:10:57 +0200 [thread overview]
Message-ID: <ZAilganP5W3sCgG1@intel.com> (raw)
In-Reply-To: <20230227040324.130811-4-ankit.k.nautiyal@intel.com>
On Mon, Feb 27, 2023 at 09:33:14AM +0530, Ankit Nautiyal wrote:
> For YCbCr420 output, scaler is required for downsampling.
> Scaler can be used only when source size smaller than max_src_w and
> max_src_h as defined by for the platform.
> So go for native YCbCr420 only if there are no scaler constraints.
>
> v2: Corrected max-width based on Display Version.
>
> v3: Updated max-width as per latest Bspec change.
>
> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 41 ++++++++++++++++++++++---
> 1 file changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 1a30cc021b25..e95fc0f0d13a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -804,11 +804,36 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> return 0;
> }
>
> +static bool
> +ycbcr420_scaler_constraints(struct drm_i915_private *i915,
> + const struct drm_display_mode *mode)
> +{
> + int max_src_w, max_src_h;
> +
> + if (DISPLAY_VER(i915) < 11) {
> + max_src_w = 4096;
> + max_src_h = 4096;
> + } else if (DISPLAY_VER(i915) < 12) {
> + max_src_w = 5120;
> + max_src_h = 4096;
> + } else if (DISPLAY_VER(i915) < 14) {
> + max_src_w = 5120;
> + max_src_h = 8192;
> + } else {
> + max_src_w = 4096;
> + max_src_h = 8192;
> + }
> +
> + return mode->hdisplay > max_src_w || mode->vdisplay > max_src_h;
> +}
> +
I don't really like this. If we do something like this
then it should be the scaler code that checks this stuff.
However, after pondering about this more I'm actually
leaning towards using 4:4:4 output whenever possible,
only going for 4:2:0 if absolutely necessary. That
avoids having to deal with all the annoying scaler/etc
limitations.
> static enum intel_output_format
> intel_dp_output_format(struct intel_connector *connector,
> + const struct drm_display_mode *mode,
> enum intel_output_format sink_format)
> {
> struct intel_dp *intel_dp = intel_attached_dp(connector);
> + struct drm_i915_private *i915 = to_i915(connector->base.dev);
>
> if (!connector->base.ycbcr_420_allowed ||
> sink_format != INTEL_OUTPUT_FORMAT_YCBCR420)
> @@ -820,8 +845,15 @@ intel_dp_output_format(struct intel_connector *connector,
>
> if (intel_dp->dfp.ycbcr_444_to_420)
> return INTEL_OUTPUT_FORMAT_YCBCR444;
> - else
> +
> + /*
> + * For YCbCr420 output, scaler is required for downsampling
> + * So go for native YCbCr420 only if there are no scaler constraints.
> + */
> + if (!ycbcr420_scaler_constraints(i915, mode))
> return INTEL_OUTPUT_FORMAT_YCBCR420;
> +
> + return INTEL_OUTPUT_FORMAT_RGB;
> }
>
> int intel_dp_min_bpp(enum intel_output_format output_format)
> @@ -857,7 +889,7 @@ intel_dp_mode_min_output_bpp(struct intel_connector *connector,
> else
> sink_format = INTEL_OUTPUT_FORMAT_RGB;
>
> - output_format = intel_dp_output_format(connector, sink_format);
> + output_format = intel_dp_output_format(connector, mode, sink_format);
>
> return intel_dp_output_bpp(output_format, intel_dp_min_bpp(output_format));
> }
> @@ -2052,7 +2084,8 @@ intel_dp_compute_output_format(struct intel_encoder *encoder,
> crtc_state->sink_format = INTEL_OUTPUT_FORMAT_RGB;
> }
>
> - crtc_state->output_format = intel_dp_output_format(connector, crtc_state->sink_format);
> + crtc_state->output_format = intel_dp_output_format(connector, adjusted_mode,
> + crtc_state->sink_format);
>
> ret = intel_dp_compute_link_config(encoder, crtc_state, conn_state,
> respect_downstream_limits);
> @@ -2063,7 +2096,7 @@ intel_dp_compute_output_format(struct intel_encoder *encoder,
> return ret;
>
> crtc_state->sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> - crtc_state->output_format = intel_dp_output_format(connector,
> + crtc_state->output_format = intel_dp_output_format(connector, adjusted_mode,
> crtc_state->sink_format);
> ret = intel_dp_compute_link_config(encoder, crtc_state, conn_state,
> respect_downstream_limits);
> --
> 2.25.1
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2023-03-08 15:11 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-27 4:03 [Intel-gfx] [PATCH v10 00/13] Handle BPC for HDMI2.1 PCON without DSC1.2 sink and other fixes Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 01/13] drm/i915/display: Add new member to configure PCON color conversion Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 02/13] drm/i915/display: Add new member in intel_dp to store ycbcr420 passthrough cap Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 03/13] drm/i915/dp: Add Scaler constraint for YCbCr420 output Ankit Nautiyal
2023-03-08 15:10 ` Ville Syrjälä [this message]
2023-03-08 15:26 ` Ville Syrjälä
2023-03-09 8:31 ` Nautiyal, Ankit K
2023-03-09 10:21 ` Ville Syrjälä
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 04/13] drm/i915/dp: Replace intel_dp.dfp members with the new crtc_state sink_format Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 05/13] drm/i915/dp: Compute output format with/without DSC Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 06/13] drm/i915/display: Use sink_format instead of ycbcr420_output flag Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 07/13] drm/i915/dp: Rearrange check for illegal mode and comments in mode_valid Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 08/13] drm/i915/dp: Consider output_format while computing dsc bpp for mode_valid Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 09/13] drm/i915/display: Add helper function to check if sink_format is 420 Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 10/13] drm/i915/dp: Avoid DSC with output_format YCBCR420 Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 11/13] drm/i915/dp: Handle BPP where HDMI2.1 DFP doesn't support DSC Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 12/13] drm/i915/dp: Fix FRL BW check for HDMI2.1 DFP Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 13/13] drm/i915/dp: Add a wrapper to check frl/tmds downstream constraints Ankit Nautiyal
2023-02-27 5:13 ` [Intel-gfx] ✓ Fi.CI.BAT: success for Handle BPC for HDMI2.1 PCON without DSC1.2 sink and other fixes (rev11) Patchwork
2023-02-27 7:04 ` [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=ZAilganP5W3sCgG1@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox