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;
>
next prev 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