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

[Yongxing Mou <yongxing.mou@oss.qualcomm.com>]

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.
>> 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@oss.qualcomm.com>
>