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.
> 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.
>
> 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@oss.qualcomm.com>
--
With best wishes
Dmitry