From: Takashi Iwai <tiwai@suse.de>
To: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Cc: Mark Brown <broonie@kernel.org>, Takashi Iwai <tiwai@suse.com>,
linux-sound <linux-sound@vger.kernel.org>,
wtaymans@redhat.com, arun@asymptotic.io,
Jaroslav Kysela <perex@perex.cz>,
lkml <linux-kernel@vger.kernel.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Subject: Re: DP/HDMI Jack and Pipewire
Date: Sat, 08 Nov 2025 10:21:01 +0100 [thread overview]
Message-ID: <874ir4ribm.wl-tiwai@suse.de> (raw)
In-Reply-To: <76b8ca1d-040b-472e-9804-5c0c0100b5b5@oss.qualcomm.com>
On Fri, 07 Nov 2025 11:15:50 +0100,
Srinivas Kandagatla wrote:
>
> 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
I believe this has been a long-standing problem even for HD-audio.
The HD-audio HDMI driver does open and process without actual pin
setup for allowing the probe by PA/PW with the assumption of some
basic PCM parameters. It was introduced in the commit
42b2987079eca0238b576c08af1144ed5bd52188
ALSA: hda - hdmi playback without monitor in dynamic pcm bind mode
So I find using a dummy ops would make sense (assuming it's actually
enough to convince PA/PW).
thanks,
Takashi
next prev parent reply other threads:[~2025-11-08 9:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-07 10:15 DP/HDMI Jack and Pipewire Srinivas Kandagatla
2025-11-08 9:21 ` Takashi Iwai [this message]
2025-11-09 11:43 ` Jaroslav Kysela
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874ir4ribm.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=arun@asymptotic.io \
--cc=broonie@kernel.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=krzk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=srinivas.kandagatla@oss.qualcomm.com \
--cc=tiwai@suse.com \
--cc=wtaymans@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.