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

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

On 11/9/2026 3:25 AM, Dmitry Baryshkov wrote:
> On Tue, Oct 27, 2026 at 10:04:54PM +0100, Robert Meijers wrote:
>> Hi,
>>
>> ((Sorry, re-sending because the first was rejected for not being plain
>> text))
>> (First up this is the first time I'm participating on a mailing list,
>> so sorry in advance if I'm doing something wrong).
>>
>>> 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.
>> I have applied this patch series onto a near mainline 7.3 tree for the
>> Xiaomi Pad 6s Pro ("Sheng"), with SM8550. But with these patches
>> applied I don't have working audio, over USB-C to my (DisplayPort)
>> monitor, anymore. If I disable MST support on the monitor audio works
>> again. Debugging (using AI) reveals that the DP0 Jack is not reported as
>> connected anymore when connected to the monitor, with these patches
>> applied and MST enabled on the monitor. As shown, for example, by
>> amixer:
>>
>> $ amixer -c 0 contents | grep -i -A8 -B3 -E 'hdmi|displayport|jack'
>> numid=208,iface=CARD,name='DP0 Jack'
>> ; type=BOOLEAN,access=r-------,values=1
>> : values=off
>>
>> With MST on the monitor disabled this outputs "values=on". The same is
>> also reflected by "pactl list cards" and "pactl list sinks" where
>> HDMI/DisplayPort is reported as "not available" with MST enabled (and
>> "available" when disabling MST).
>>
>> (Again, suggested by AI) I also checked the ELD, which in both
>> cases (MST on and off on the monitor) is identical, including audio
>> information (like "speakers [0x1] FL/FR"). (Also, audio works both using
>> an AMD and an Intel based laptop, in which case I can also choose
>> whether to use "HDMI" or "HDMI 2" to switch audio output between two
>> monitors, in daisy chain).
>>
>> So my foremost question is: should audio be supported in case of MST,
>> after applying these patches? Or is this possibly out of scope?
> 
> I'd say, it was out of scope for now.
> 
>> For clarity I would also like to note that without these patches
>> applied audio over DP does work as well, irrespective of MST being
>> on or off on the monitor (obviously always running as SST because of
>> missing kernel support). Which would make me believe that no audio
>> support in the same setup might be considered a regression?
> 
> Technically you are right, it is a regression in your case.
> 
> Yongxing, how difficult would it be to support audio over the MST?
> 
I don't think it should be too difficult. It would mainly involve 
programming some audio-related registers for each MST stream. But I 
haven't actually tried it yet.
>>
>> Note that I do understand that me running a forked kernel on a
>> (by upstream) unsupported device might also lead to issues or require
>> changes for the fork. And that if audio does work with MST then this is
>> something the maintainers of the fork should, most likely, fix. But
>> from the cover letter and commit messages it is unclear to me whether
>> audio support should work and/or has been tested when MST is in use.
>>
>> Kind regards,
>> Robert
>>
>