Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Hogander, Jouni" <jouni.hogander@intel.com>
To: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Deak, Imre" <imre.deak@intel.com>
Subject: Re: [PATCH] drm/i915/dp_mst: Fix check for FEC support for an uncompressed stream
Date: Wed, 29 Oct 2025 14:06:07 +0000	[thread overview]
Message-ID: <6a63fe2775f399458527be8d55e781644945669f.camel@intel.com> (raw)
In-Reply-To: <20251028113536.602352-1-imre.deak@intel.com>

On Tue, 2025-10-28 at 13:35 +0200, Imre Deak wrote:
> The reason for enabling FEC for an uncompressed stream on an MST link
> is
> that the DSC compression is enabled for another stream on the same
> link.
> For such an uncompressed stream FEC doesn't need to be supported on
> the
> whole path until the (DP-SST) sink DPRX. For instance if a branch
> device
> - like a monitor with an MST branch device within it - is plugged to
> a
> DFP connector of an MST docking station and the monitor's branch
> device does not support FEC, the docking station's branch device will
> still enable the link to the monitor correctly, disabling the FEC on
> that link as expected. Since it's been verified already that FEC is
> supported for the compressed stream above, the corresponding check
> for
> the uncompressed stream can be dropped: the check for the compressed
> stream implies already that FEC is supported on the link between the
> source DPTX and immediate downstream branch device. If FEC is not
> supported on the whole path until the sink DPRX, FEC will be disabled
> by
> a downstream branch device on the path as described above for the MST
> dock + MST monitor configuration example.
> 
> This fixes a problem in the above MST dock + MST monitor example,
> where
> the dock supports FEC, but the monitor doesn't support it and FEC
> gets
> enabled on the link due to DSC getting enabled for another monitor's
> stream on the same link.
> 
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14254
> Signed-off-by: Imre Deak <imre.deak@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index a845b2612a3fa..21a60b8c880ee 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -299,7 +299,14 @@ int intel_dp_mtp_tu_compute_config(struct
> intel_dp *intel_dp,
>  	 * intel_dp_needs_8b10b_fec().
>  	 */
>  	crtc_state->fec_enable =
> intel_dp_needs_8b10b_fec(crtc_state, dsc);
> -	if (crtc_state->fec_enable &&
> +	/*
> +	 * If FEC gets enabled only because of another compressed
> stream, FEC
> +	 * may not be supported for this uncompressed stream on the
> whole link
> +	 * path until the sink DPRX. In this case a downstream
> branch device
> +	 * will disable FEC for the uncompressed stream as expected
> and so the
> +	 * FEC support doesn't need to be checked for this
> uncompressed stream.
> +	 */
> +	if (crtc_state->fec_enable && dsc &&

Why crtc_state->fec_enable is set if it's not going to enabled and not
even supported in the crtc this crtc_state is for?

Also there seems to be very similar check in mst_stream_compute_config.
Do we need to change that as well?

BR,

Jouni Högander

>  	    !intel_dp_supports_fec(intel_dp, connector, crtc_state))
>  		return -EINVAL;
>  


  parent reply	other threads:[~2025-10-29 14:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-28 11:35 [PATCH] drm/i915/dp_mst: Fix check for FEC support for an uncompressed stream Imre Deak
2025-10-28 12:58 ` ✓ i915.CI.BAT: success for " Patchwork
2025-10-28 21:34 ` ✗ i915.CI.Full: failure " Patchwork
2025-10-29 18:04   ` Imre Deak
2025-10-29 14:06 ` Hogander, Jouni [this message]
2025-10-29 14:17   ` [PATCH] " Imre Deak
2025-10-29 15:06     ` Hogander, Jouni

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=6a63fe2775f399458527be8d55e781644945669f.camel@intel.com \
    --to=jouni.hogander@intel.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@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