Re: [PATCH v4 00/39] drm/msm/dp: Add MST support for MSM chipsets

[Dmitry Baryshkov]

On Fri, May 22, 2026 at 04:07:52PM +0800, Yongxing Mou wrote:
> 
> 
> On 4/12/2026 8:34 AM, Dmitry Baryshkov wrote:
> > On Fri, Apr 10, 2026 at 05:33:35PM +0800, Yongxing Mou wrote:
> > > Add support for Multi-stream transport for MSM chipsets that allow
> > > a single instance of DP controller to send multiple streams.
> > > 
> > > This series has been validated on sa8775p ride platform using multiple
> > > MST dongles and also daisy chain method on both DP0 and DP1 upto 1080P.
> > > 
> > > With 4x4K monitors, due to lack of layer mixers that combination will not
> > > work but this can be supported as well after some rework on the DPU side.
> > > 
> > > In addition, SST was re-validated with all these changes to ensure there
> > > were no regressions.
> > > 
> > > This patch series was made on top of:
> > > 
> > > [1] : https://patchwork.freedesktop.org/series/151522/ (v5 to fix up HPD)
> > > 
> > > Overall, the patch series has been organized in the following way:
> > > 
> > > 1) First set are a couple of fixes made while debugging MST but applicable
> > > to SST as well so go ahead of everything else
> > > 2) Prepare the DP driver to get ready to handle multiple streams. This is the bulk
> > > of the work as current DP driver design had to be adjusted to make this happen.
> > > 3) Finally, new files to handle MST related operations
> > 
> > General suggestion. Please reorg the series into the more logical
> > chunks. If you are touching enable / disable path, then continue doing
> > that until its done (more or less). I'd really like to be able to merge
> > at least a part of the series in the next cycle, but there needs to be a
> > logical "halfway done" moment. Let's define it at the "all paths are
> > refactored, all booleans are in place, we are ready to get MST parts".
> > 
> > I've not found a use for separate bridges in the MST path. Please split
> > the functionality between the MST connector and, maybe, another private
> > object for generic state (like connector -> encoder mapping). Other
> > drivers don't have this issue because they have fixed CRTC -> encoder
> > mapping. MSM doesn't so we need a separate way to store that. It's sad
> > that we can't subclass MST topology manager (or its state). Maybe it
> > would be worth changing that and letting our topology manager handle the
> > assignment in it.
> > 
> > Also, I found a set of warnings while trying to build the code. Please
> > make sure that there are no warnings.
> > 
> Got it, thanks...
> Does this mean I can send a subset first (rebase on latest linux-next and ),
> for example the first twelve patches? They are mainly clean-up changes and
> do not touch the MST part yet.

Yes. Keep the version numbers increasing and document in the cover letter
that it's a spin-off of the MST series.

> > > Note:
> > > Validation for this series has so far been done on the latest linux-next
> > > on LeMans, covering both FB console and Weston.
> > 
> > It wasn't. I couldn't apply it to the latest linux-next. There were
> > fuzz-based rejections because of one of the patches merged some time
> > ago.
> > 
> Will rebase it.>>
> > > Broader validation, including additional Type-C DP use cases, is still
> > > in progress and may lead to some follow-up adjustments in the next
> > > revision. I wanted to post the current version first to collect early
> > > feedback on the overall approach.
> > 
> > It's nice, but please keep in mind that majority of users use Type-C
> > rather than native DP connectors. In some cases your lack of Type-C
> > testing affects the design (e.g. for the HPD handling).
> > 
> > > 
> > > Signed-off-by: Yongxing Mou <yongxing.mou@xxxxxxxxxxxxxxxx>
> > 
> 

-- 
With best wishes
Dmitry