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 <[email protected]> > > > -- With best wishes Dmitry
