> -----Original Message-----
> From: Golani, Mitulkumar Ajitkumar
> <[email protected]>
> Sent: 22 October 2026 22:11
> To: Kandpal, Suraj <[email protected]>; [email protected];
> [email protected]
> Cc: Nautiyal, Ankit K <[email protected]>; Murthy, Arun R
> <[email protected]>
> Subject: RE: [PATCH v4 03/10] drm/i915/dp_mst: Limit M/N ratio for MST
>
>
>
> > -----Original Message-----
> > From: Kandpal, Suraj <[email protected]>
> > Sent: 21 October 2026 10:39
> > To: Golani, Mitulkumar Ajitkumar
> > <[email protected]>;
> > [email protected]; [email protected]
> > Cc: Nautiyal, Ankit K <[email protected]>; Murthy, Arun R
> > <[email protected]>
> > Subject: RE: [PATCH v4 03/10] drm/i915/dp_mst: Limit M/N ratio for MST
> >
> >
> >
> > > -----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
>
> Could we double-check the MST path here ?
>
> My understanding is that DG2 supports UHBR, and
> intel_dp_compute_config_limits pins link_config_filter to the max-BW config
> for MST before the M/N ratio filtering runs.
> If that config fails the ratio check, would the stream be rejected rather than
> falling back to HBR3 ?
>
> Also, since mst_stream_compute_link_config uses the same max-BW config
> for port_clock, should mode_valid check the ratio against that config as well,
> rather than accepting the mode based on any allowed config?
>
What would you propose as a fix for this.
Regards,
Suraj Kandpal
> >
> > >
> > > > +
> > > > /*
> > > > * TODO:
> > > > * - Also check if compression would allow for the mode
> > > > --
> > > > 2.34.1
