All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: intel-gfx@lists.freedesktop.org,
	Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 4/9] drm/i915/dp: Restructure the sink/output format selection
Date: Tue, 31 Mar 2026 15:35:04 +0200	[thread overview]
Message-ID: <2479715.CQOukoFCf9@workhorse> (raw)
In-Reply-To: <20260330235339.29479-5-ville.syrjala@linux.intel.com>

On Tuesday, 31 March 2026 01:53:34 Central European Summer Time Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Restructure intel_dp_compute_output_format() to resemble the new
> intel_hdmi_compute_output_formats().
> 
> Again, we basically have two main code paths:
> - YCbCr 4:2:0 only modes
> - everything else including YCbCr 4:2:0 also modes
> 
> Take the exact same approach with the DP code, making the
> format selection much less convoluted.
> 
> Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 98 +++++++++++++++++--------
>  1 file changed, 69 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4955bd8b11d7..230b45acde29 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1371,6 +1371,28 @@ intel_dp_mode_valid_downstream(struct intel_connector *connector,
>  	return MODE_OK;
>  }
>  
> +static enum drm_mode_status
> +intel_dp_sink_format_valid(struct intel_connector *connector,
> +			   const struct drm_display_mode *mode,
> +			   enum intel_output_format sink_format)
> +{
> +	const struct drm_display_info *info = &connector->base.display_info;
> +
> +	switch (sink_format) {
> +	case INTEL_OUTPUT_FORMAT_YCBCR420:
> +		if (!connector->base.ycbcr_420_allowed ||
> +		    !drm_mode_is_420(info, mode))
> +			return MODE_NO_420;
> +
> +		return MODE_OK;
> +	case INTEL_OUTPUT_FORMAT_RGB:
> +		return MODE_OK;
> +	default:
> +		MISSING_CASE(sink_format);
> +		return MODE_BAD;
> +	}
> +}
> +

I think here we'll want another
---
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index e23162fc3f8b..a1dc089c54f5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1373,6 +1373,11 @@ intel_dp_sink_format_valid(struct intel_connector *connector,
 
                return MODE_OK;
        case INTEL_OUTPUT_FORMAT_RGB:
+               return MODE_OK;
+       case INTEL_OUTPUT_FORMAT_YCBCR444:
+               if (!(info->color_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444)))
+                       return MODE_BAD;
+
                return MODE_OK;
        default:
                MISSING_CASE(sink_format);
---

though this time, no bpc related changes. With that fixed, I get
YCbCr444 at 10bpc as well as 8bpc. Can't test 4:2:0 for what appears
to be unrelated userspace reasons, though the KMS property's enum
value is exposed properly.

>  int intel_dp_max_hdisplay_per_pipe(struct intel_display *display)
>  {
>  	return DISPLAY_VER(display) >= 30 ? 6144 : 5120;
> @@ -3330,41 +3352,59 @@ static int
>  intel_dp_compute_output_format(struct intel_encoder *encoder,
>  			       struct intel_crtc_state *crtc_state,
>  			       struct drm_connector_state *conn_state,
> -			       bool respect_downstream_limits)
> +			       bool respect_downstream_limits,
> +			       enum intel_output_format sink_format)
>  {
> -	struct intel_display *display = to_intel_display(encoder);
>  	struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>  	struct intel_connector *connector = intel_dp->attached_connector;
> -	const struct drm_display_info *info = &connector->base.display_info;
>  	const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
> -	bool ycbcr_420_only;
> -	int ret;
>  
> -	ycbcr_420_only = drm_mode_is_420_only(info, adjusted_mode);
> -
> -	if (ycbcr_420_only && !connector->base.ycbcr_420_allowed) {
> -		drm_dbg_kms(display->drm,
> -			    "YCbCr 4:2:0 mode but YCbCr 4:2:0 output not possible. Falling back to RGB.\n");
> -		crtc_state->sink_format = INTEL_OUTPUT_FORMAT_RGB;
> -	} else {
> -		crtc_state->sink_format = intel_dp_sink_format(connector, adjusted_mode);
> -	}
> +	if (intel_dp_sink_format_valid(connector, adjusted_mode,
> +				       sink_format) != MODE_OK)
> +		return -EINVAL;
>  
> +	crtc_state->sink_format = sink_format;
>  	crtc_state->output_format = intel_dp_output_format(connector, crtc_state->sink_format);
>  
> -	ret = intel_dp_compute_link_config(encoder, crtc_state, conn_state,
> -					   respect_downstream_limits);
> -	if (ret) {
> -		if (crtc_state->sink_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
> -		    !connector->base.ycbcr_420_allowed ||
> -		    !drm_mode_is_420_also(info, adjusted_mode))
> -			return ret;
> -
> -		crtc_state->sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> -		crtc_state->output_format = intel_dp_output_format(connector,
> -								   crtc_state->sink_format);
> -		ret = intel_dp_compute_link_config(encoder, crtc_state, conn_state,
> -						   respect_downstream_limits);
> +	return intel_dp_compute_link_config(encoder, crtc_state, conn_state,
> +					    respect_downstream_limits);

With the removal of intel_dp_sink_format in this function, I wonder
if we can get rid of it entirely now. It's only called in
intel_dp_mode_min_link_bpp_x16, which seems to be used for bandwidth
limitation calculations (where YCbCr444 vs RGB444 doesn't matter, so
we're fine in that regard).

Judging by the "min" in the function name, I assume it should be
using INTEL_OUTPUT_FORMAT_YCBCR420 in drm_mode_is_420_also cases,
whereas right now it only gets this from intel_dp_sink_format if
the mode is drm_mode_is_420_only. So I think removing
intel_dp_sink_format entirely as a follow-up, and folding a
corrected minimum bandwidth computation that uses 420 if
drm_mode_is_420 into intel_dp_mode_min_link_bpp_x16 would make
sense, unless I'm totally misunderstanding the code here.

> +}
> +
> +static int
> +intel_dp_compute_formats(struct intel_encoder *encoder,
> +			 struct intel_crtc_state *crtc_state,
> +			 struct drm_connector_state *conn_state,
> +			 bool respect_downstream_limits)
> +{
> +	struct intel_display *display = to_intel_display(encoder);
> +	struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +	struct intel_connector *connector = intel_dp->attached_connector;
> +	const struct drm_display_info *info = &connector->base.display_info;
> +	const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
> +	int ret;
> +
> +	if (drm_mode_is_420_only(info, adjusted_mode)) {
> +		ret = intel_dp_compute_output_format(encoder, crtc_state, conn_state,
> +						     respect_downstream_limits,
> +						     INTEL_OUTPUT_FORMAT_YCBCR420);
> +
> +		if (ret) {
> +			drm_dbg_kms(display->drm,
> +				    "YCbCr 4:2:0 mode but YCbCr 4:2:0 output not possible. Falling back to RGB.\n");
> +
> +			ret = intel_dp_compute_output_format(encoder, crtc_state, conn_state,
> +							     respect_downstream_limits,
> +							     INTEL_OUTPUT_FORMAT_RGB);
> +		}
> +	} else {
> +		ret = intel_dp_compute_output_format(encoder, crtc_state, conn_state,
> +						     respect_downstream_limits,
> +						     INTEL_OUTPUT_FORMAT_RGB);
> +
> +		if (ret && drm_mode_is_420_also(info, adjusted_mode))
> +			ret = intel_dp_compute_output_format(encoder, crtc_state, conn_state,
> +							     respect_downstream_limits,
> +							     INTEL_OUTPUT_FORMAT_YCBCR420);
>  	}
>  
>  	return ret;
> @@ -3539,9 +3579,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>  	 * Try to respect downstream TMDS clock limits first, if
>  	 * that fails assume the user might know something we don't.
>  	 */
> -	ret = intel_dp_compute_output_format(encoder, pipe_config, conn_state, true);
> +	ret = intel_dp_compute_formats(encoder, pipe_config, conn_state, true);
>  	if (ret)
> -		ret = intel_dp_compute_output_format(encoder, pipe_config, conn_state, false);
> +		ret = intel_dp_compute_formats(encoder, pipe_config, conn_state, false);
>  	if (ret)
>  		return ret;
>  
> 





  reply	other threads:[~2026-03-31 13:35 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-30 23:53 [PATCH 0/9] drm/i915/{dp, hdmi}: Restructure DP/HDMI sink format handling Ville Syrjala
2026-03-30 23:53 ` [PATCH 1/9] drm/i915/hdmi: Add missing intel_pfit_mode_valid() for 4:2:0 also modes Ville Syrjala
2026-04-06  5:23   ` Nautiyal, Ankit K
2026-03-30 23:53 ` [PATCH 2/9] drm/i915/hdmi: Restructure the sink/output format selection Ville Syrjala
2026-03-31 12:12   ` Nicolas Frattaroli
2026-04-06  5:26     ` Nautiyal, Ankit K
2026-04-07  7:14       ` Nicolas Frattaroli
2026-04-06  5:27   ` Nautiyal, Ankit K
2026-03-30 23:53 ` [PATCH 3/9] drm/i915/hdmi: Restructure 4:2:0 vs. 4:4:4 mode validation Ville Syrjala
2026-04-06  5:28   ` Nautiyal, Ankit K
2026-03-30 23:53 ` [PATCH 4/9] drm/i915/dp: Restructure the sink/output format selection Ville Syrjala
2026-03-31 13:35   ` Nicolas Frattaroli [this message]
2026-04-06  5:32     ` Nautiyal, Ankit K
2026-04-07 18:00       ` Ville Syrjälä
2026-04-07 18:20         ` Ville Syrjälä
2026-03-30 23:53 ` [PATCH 5/9] drm/i915/dp: Validate "4:2:0 also" modes twice Ville Syrjala
2026-04-06  8:45   ` Nautiyal, Ankit K
2026-03-30 23:53 ` [PATCH 6/9] drm/i915/dp: Require a HDMI sink for YCbCr output via PCON Ville Syrjala
2026-04-06  8:46   ` Nautiyal, Ankit K
2026-03-30 23:53 ` [PATCH 7/9] drm/i915/dp: Validate sink format in .mode_valid() Ville Syrjala
2026-04-06  8:51   ` Nautiyal, Ankit K
2026-03-30 23:53 ` [PATCH 8/9] drm/i915/hdmi: Make the RGB fallback for "4:2:0 only" modes the last resort Ville Syrjala
2026-04-06  8:52   ` Nautiyal, Ankit K
2026-03-30 23:53 ` [PATCH 9/9] drm/i915/dp: " Ville Syrjala
2026-04-06  8:52   ` Nautiyal, Ankit K
2026-03-31  0:01 ` ✓ CI.KUnit: success for drm/i915/{dp, hdmi}: Restructure DP/HDMI sink format handling Patchwork
2026-03-31  0:40 ` ✓ Xe.CI.BAT: " Patchwork
2026-03-31  0:50 ` ✓ i915.CI.BAT: " Patchwork
2026-03-31  4:42 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-03-31  7:46 ` ✗ i915.CI.Full: " 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=2479715.CQOukoFCf9@workhorse \
    --to=nicolas.frattaroli@collabora.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.com \
    /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.