public inbox for intel-xe@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
	<intel-gfx@lists.freedesktop.org>
Cc: <intel-xe@lists.freedesktop.org>,
	Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Subject: Re: [PATCH 5/9] drm/i915/dp: Validate "4:2:0 also" modes twice
Date: Mon, 6 Apr 2026 14:15:21 +0530	[thread overview]
Message-ID: <538fcd49-d6d9-4234-9064-5b8076a047c9@intel.com> (raw)
In-Reply-To: <20260330235339.29479-6-ville.syrjala@linux.intel.com>


On 3/31/2026 5:23 AM, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Currently we only validate "4:2:0 also" modes as RGB. But
> if that fails we could perhaps still use the mode in with
> 4:2:0 output. All we have to do is retry the validation with
> the different sink format.
>
> So far we did the double validation only so far as it affects
> PCON TMDS clock limits. But validating everything twice seems
> a bit more sane.
>
> Note that intel_dp_output_format() might still end up picking
> RGB for the actual output format (and letting PCON deal with
> the YCbCr conversion). So I suppose we could still fail the
> validation due to that, and forcing even the output format
> to 4:2:0 might solve it on a third try. But we'd need the
> same fallback logic in intel_dp_compute_config(). For now
> this seems sufficient.
>
> 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 | 114 +++++++++++++-----------
>   1 file changed, 61 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 230b45acde29..86319bf09a19 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1320,12 +1320,10 @@ intel_dp_tmds_clock_valid(struct intel_dp *intel_dp,
>   static enum drm_mode_status
>   intel_dp_mode_valid_downstream(struct intel_connector *connector,
>   			       const struct drm_display_mode *mode,
> -			       int target_clock)
> +			       int target_clock,
> +			       enum intel_output_format sink_format)
>   {
>   	struct intel_dp *intel_dp = intel_attached_dp(connector);
> -	const struct drm_display_info *info = &connector->base.display_info;
> -	enum drm_mode_status status;
> -	enum intel_output_format sink_format;
>   
>   	/* If PCON supports FRL MODE, check FRL bandwidth constraints */
>   	if (intel_dp->dfp.pcon_max_frl_bw) {
> @@ -1350,25 +1348,9 @@ intel_dp_mode_valid_downstream(struct intel_connector *connector,
>   	    target_clock > intel_dp->dfp.max_dotclock)
>   		return MODE_CLOCK_HIGH;
>   
> -	sink_format = intel_dp_sink_format(connector, mode);
> -
>   	/* Assume 8bpc for the DP++/HDMI/DVI TMDS clock check */
> -	status = intel_dp_tmds_clock_valid(intel_dp, target_clock,
> -					   8, sink_format, true);
> -
> -	if (status != MODE_OK) {
> -		if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
> -		    !connector->base.ycbcr_420_allowed ||
> -		    !drm_mode_is_420_also(info, mode))
> -			return status;
> -		sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> -		status = intel_dp_tmds_clock_valid(intel_dp, target_clock,
> -						   8, sink_format, true);
> -		if (status != MODE_OK)
> -			return status;
> -	}
> -
> -	return MODE_OK;
> +	return intel_dp_tmds_clock_valid(intel_dp, target_clock,
> +					 8, sink_format, true);
>   }
>   
>   static enum drm_mode_status
> @@ -1464,15 +1446,14 @@ bool intel_dp_dotclk_valid(struct intel_display *display,
>   }
>   
>   static enum drm_mode_status
> -intel_dp_mode_valid(struct drm_connector *_connector,
> -		    const struct drm_display_mode *mode)
> +intel_dp_mode_valid_format(struct intel_connector *connector,
> +			   const struct drm_display_mode *mode,
> +			   int target_clock,
> +			   enum intel_output_format sink_format)
>   {
> -	struct intel_display *display = to_intel_display(_connector->dev);
> -	struct intel_connector *connector = to_intel_connector(_connector);
> +	struct intel_display *display = to_intel_display(connector);
>   	struct intel_dp *intel_dp = intel_attached_dp(connector);
> -	enum intel_output_format sink_format, output_format;
> -	const struct drm_display_mode *fixed_mode;
> -	int target_clock = mode->clock;
> +	enum intel_output_format output_format;
>   	int max_rate, mode_rate, max_lanes, max_link_clock;
>   	u16 dsc_max_compressed_bpp = 0;
>   	enum drm_mode_status status;
> @@ -1480,29 +1461,6 @@ intel_dp_mode_valid(struct drm_connector *_connector,
>   	int num_joined_pipes;
>   	int link_bpp_x16;
>   
> -	status = intel_cpu_transcoder_mode_valid(display, mode);
> -	if (status != MODE_OK)
> -		return status;
> -
> -	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> -		return MODE_H_ILLEGAL;
> -
> -	if (mode->clock < 10000)
> -		return MODE_CLOCK_LOW;
> -
> -	if (intel_dp_hdisplay_bad(display, mode->hdisplay))
> -		return MODE_H_ILLEGAL;
> -
> -	fixed_mode = intel_panel_fixed_mode(connector, mode);
> -	if (intel_dp_is_edp(intel_dp) && fixed_mode) {
> -		status = intel_panel_mode_valid(connector, mode);
> -		if (status != MODE_OK)
> -			return status;
> -
> -		target_clock = fixed_mode->clock;
> -	}
> -
> -	sink_format = intel_dp_sink_format(connector, mode);
>   	output_format = intel_dp_output_format(connector, sink_format);
>   
>   	max_link_clock = intel_dp_max_link_rate(intel_dp);
> @@ -1600,7 +1558,57 @@ intel_dp_mode_valid(struct drm_connector *_connector,
>   	if (status != MODE_OK)
>   		return status;
>   
> -	return intel_dp_mode_valid_downstream(connector, mode, target_clock);
> +	return intel_dp_mode_valid_downstream(connector, mode,
> +					      target_clock, sink_format);
> +}
> +
> +static enum drm_mode_status
> +intel_dp_mode_valid(struct drm_connector *_connector,
> +		    const struct drm_display_mode *mode)
> +{
> +	struct intel_display *display = to_intel_display(_connector->dev);
> +	struct intel_connector *connector = to_intel_connector(_connector);
> +	const struct drm_display_info *info = &connector->base.display_info;
> +	struct intel_dp *intel_dp = intel_attached_dp(connector);
> +	const struct drm_display_mode *fixed_mode;
> +	int target_clock = mode->clock;
> +	enum drm_mode_status status;
> +
> +	status = intel_cpu_transcoder_mode_valid(display, mode);
> +	if (status != MODE_OK)
> +		return status;
> +
> +	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> +		return MODE_H_ILLEGAL;
> +
> +	if (mode->clock < 10000)
> +		return MODE_CLOCK_LOW;
> +
> +	if (intel_dp_hdisplay_bad(display, mode->hdisplay))
> +		return MODE_H_ILLEGAL;
> +
> +	fixed_mode = intel_panel_fixed_mode(connector, mode);
> +	if (intel_dp_is_edp(intel_dp) && fixed_mode) {
> +		status = intel_panel_mode_valid(connector, mode);
> +		if (status != MODE_OK)
> +			return status;
> +
> +		target_clock = fixed_mode->clock;
> +	}
> +
> +	if (drm_mode_is_420_only(info, mode)) {
> +		status = intel_dp_mode_valid_format(connector, mode, target_clock,
> +						    INTEL_OUTPUT_FORMAT_YCBCR420);
> +	} else {
> +		status = intel_dp_mode_valid_format(connector, mode, target_clock,
> +						    INTEL_OUTPUT_FORMAT_RGB);
> +

Perhaps we can write  a comment or TODO here about the PCON special case 
which you mentioned:

that even though we are trying 420 sink output format, with PCON it is 
possible that RGB output format gets picked up (if Pcon supports color 
conversion).

In which case the rest of the mode validation will be wrt to RGB. Unless 
we handle fallback in intel_dp_output_format().


In any case, the patch LGTM.

Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>


> +		if (status != MODE_OK && drm_mode_is_420_also(info, mode))
> +			status = intel_dp_mode_valid_format(connector, mode, target_clock,
> +							    INTEL_OUTPUT_FORMAT_YCBCR420);
> +	}
> +
> +	return status;
>   }
>   
>   bool intel_dp_source_supports_tps3(struct intel_display *display)

  reply	other threads:[~2026-04-06  8:45 UTC|newest]

Thread overview: 28+ 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
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 [this message]
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  4:42 ` ✗ Xe.CI.FULL: failure " 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=538fcd49-d6d9-4234-9064-5b8076a047c9@intel.com \
    --to=ankit.k.nautiyal@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=nicolas.frattaroli@collabora.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox