[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <76b8ca1d-040b-472e-9804-5c0c0100b5b5@oss.qualcomm.com>
Date: Fri, 7 Nov 2025 10:15:50 +0000
From: Srinivas Kandagatla <srinivas.kandagatla@....qualcomm.com>
To: Mark Brown <broonie@...nel.org>, Takashi Iwai <tiwai@...e.com>
Cc: linux-sound <linux-sound@...r.kernel.org>, wtaymans@...hat.com,
arun@...mptotic.io, Jaroslav Kysela <perex@...ex.cz>,
lkml <linux-kernel@...r.kernel.org>,
Krzysztof Kozlowski <krzk@...nel.org>,
Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Subject: DP/HDMI Jack and Pipewire
Hi Everyone,
On Qualcomm platforms we have an issue enabling Display port on a full
Distro setup with pipewire and wireplumber in place.
The issue is that Display port Audio IP on Qualcomm SoC is powered off
if there is no Display connected. It make sense to keep it in this low
power mode when there is no use. And the DP IP is not expecting any data
in this state and any attempt to configure or send data would result in
error from DSP.
However, we create PCM devices and jacks for all audio sinks and
sources, including DisplayPort DAI links. When PipeWire starts up
without any awareness of jack state it probes all available PCM devices,
including the DisplayPort ones. Since no display is connected, the
prepare callback for DP fails, leading PipeWire to mark the sound card
as unusable. Consequently, it abandons entire sound card, including
other valid audio sinks. I have also started discussing this issue with
pipewire [1]
What is the expected pcm device behavior when DP jack is not connected?
Two possibilities:
1. Consume the data even when the Display is not connected. I see that
in Intel case it sinks the data somewhere and gives the user an
experience that the data is getting consumed.
2. Throw an error to user if they attempt to configure or send the data
to this disconnected pcm.
Also what userspace ABI to for such usecase?
This is blocking end-to-end DP audio enablement on Qualcomm SoCs.
Not sure if this is right approach or will work but somehow we back the
pcm devices with disconnected jack state to use dummy pcm ops instead of
actual pcm ops?
This should at least keep the pipewire happy. Is this the right approach?
[1]: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4938
Thanks,
Srini
Powered by blists - more mailing lists