> -----Original Message-----
> From: Golani, Mitulkumar Ajitkumar
> <[email protected]>
> Sent: 15 October 2026 22:59
> To: Kandpal, Suraj <[email protected]>; [email protected];
> [email protected]
> Cc: Nautiyal, Ankit K <[email protected]>; Murthy, Arun R
> <[email protected]>; Kandpal, Suraj <[email protected]>
> Subject: RE: [PATCH v4 03/10] drm/i915/dp_mst: Limit M/N ratio for MST
>
>
>
> > -----Original Message-----
> > From: Intel-gfx <[email protected]> On Behalf Of
> > Suraj Kandpal
> > Sent: 17 September 2026 10:37
> > To: [email protected]; [email protected]
> > Cc: Nautiyal, Ankit K <[email protected]>; Murthy, Arun R
> > <[email protected]>; Kandpal, Suraj <[email protected]>
> > Subject: [PATCH v4 03/10] drm/i915/dp_mst: Limit M/N ratio for MST
> >
> > From: Ankit Nautiyal <[email protected]>
> >
> > The hardware does not support DisplayPort configurations where the
> > ceiling of the Link M/Link N ratio exceeds the limit. Enforce this
> > constraint for MST as well.
> >
> > The compute config path needs no change: MST goes through
> > intel_dp_compute_config_limits() too, so the link config filter set up
> > there already excludes the configurations violating the ratio limit,
> > and MST fails there if none is left.
> >
> > What is still missing is pruning such modes, so add the check to
> > mst_connector_mode_valid_ctx(), reusing the helper the SST mode_valid
> > uses. It walks the link configurations and only rejects the mode if
> > none of them can satisfy the ratio, rather than evaluating it at a single
> > link
> rate.
> >
> > v2:
> > -Drop the checks in the MST link config helpers, redundant now that
> > the constraint is applied while computing the link config limits.
> > (Imre) -Share the mode_valid helper with SST instead of evaluating the
> > ratio at one link rate, since the link symbol clock is not monotonic
> > in the link rate and there is no single best case configuration.
> > v3:
> > -Now that intel_dp_mode_valid_m_n checks for all configs just call
> > that
> > (Sashiko)
> >
> > Signed-off-by: Ankit Nautiyal <[email protected]>
> > Signed-off-by: Suraj Kandpal <[email protected]>
> > ---
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index 0c362784afe4..823fe99ca0a1 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -1565,6 +1565,11 @@ mst_connector_mode_valid_ctx(struct
> > drm_connector *_connector,
> > min_link_bpp_x16,
> > bw_overhead_flags);
> >
> > + if (!intel_dp_mode_valid_m_n(intel_dp, mode->clock)) {
> > + *status = MODE_CLOCK_HIGH;
> > + return 0;
> > + }
>
> Since MST appears to use only the max_bw_config for link configuration,
> should the M/N ratio check in mode_valid also be performed against that
> configuration's max_link_clock? Currently, intel_dp_mode_valid_m_n
> accepts the mode if any allowed config passes the ratio check.
>
> For example, on DG2 with a UHBR10 MST link, could a ~1.3 GHz stream pass
> the check using HBR3 but later fail during config computation because MST
> uses UHBR10, which does not satisfy the ratio limit? If so, should the
> validation use the same link configuration that MST will actually use?
Lets start with DG2 does not have UHBR to begin with.
Also compute doesn't actually use max_bw_config. MST goes through
intel_dp_compute_config_limits() too, so configs that fail the ratio are already
filtered out and it picks from what's left. In your example it'd just use HBR3
instead of failing (DG2 has no UHBR anyway).
For mode_valid I didn't want to check only max_bw_config, since the symbol clock
isn't monotonic in link rate and a lower rate can pass where the max one fails.
If something slips through, compute still does the exact check.
Regards,
Suraj Kandpal
>
> > +
> > /*
> > * TODO:
> > * - Also check if compression would allow for the mode
> > --
> > 2.34.1
